Здравствуйте, Sinclair, Вы писали:

V>>Я вообще ХЗ как можно было додуматься сэкономить только на построении AST запроса.
S>Ну я просто предположил, что у любого безумия есть пределы. Скажем, выполнять оптимизацию плана исполнения в компайл-тайм — это гарантировать себе хреновую производительность на века.

Слабовато с воображением.


S>Потому что в компайл-тайм у нас нет статистики по реальным данным (а у сервера в рантайм — есть).
S>Поэтому максимум, что мы можем отправить — это тот самый декларативный запрос в терминах RA

А сколько всего может быть вариантов плана у среднего запроса?
Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
И еще в прошлый раз, когда мы обсуждали все эти вещи, я обращал твоё внимание на "повторное использование".
Например, согласно предметной области одни и те же данные в запросах часто встречаются во вполне конкретной конструкции join или её разновидности. Соответственно, всё мн-во всех вариантов планов запросов при суммировании их по всем де-факто имеющимся запросам, получается сильно ниже простой суммы всех вариантов по всем запросам.

И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
И даже с тем гипотетическим примером, приводимым в прошлый раз, когда кол-во условий зависело от каких-то флагов в ГУИ — вот прямо эти флаги в запросе и подашь, а его конкретный вид сформируется уже на сервере, т.е. эта логика из клиента уходит. ))

По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.


S>без каких-либо деталей о плане исполнения.

Без самого декларативного запроса.
Я же сразу сказал — поменяется сам принцип разработки.
Сейчас данные живут вместе с кодом в базе и сверху этого еще динамические запросы.
Придётся отделить данные от кода, код будет теперь зависеть только от схемы, а не от конкретного хранилища.
А динамическими останутся только параметры некоторых запросов.

Иначе мы ведем разговор не о статике, а не понятно о какой химере, которую ты себе вообразил. ))


S>А это и есть AST — за подробностями рекомендую почитать любой учебник по проектированию СУБД.

"Иди познакомься с синтаксисом хранимых процедур" (С)


V>>Обратно должны идти просто типизированные данные, т.е. в заведомо известной обеим сторонам разметке.
S>Подсказка: прямо сейчас это так и есть.

Классный залёт.
"Это" становится известным в рантайм, а не компайл-тайм.

Подсказка: "Иди познакомься с синтаксисом хранимых процедур" (С)


V>>Прямо сейчас всё это уже есть и отлично работает в упомянутых мною областях.
S>Чтобы аргументированно продолжать этот спор, нужно показать, как выглядит бинарное представление результата запроса select top 10 from orders order by orderDate desc в TDS, а уже затем предложить "революционные изменения".

Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
Для некоторых можно даже без регистрации скачать C-заголовки типизированных запросов + реализующие клиентские библиотеки.


S>Заодно убедительно продемонстрировать, в чём именно этот новый формат будет лучше существующего.

Наверно тем лучше, что в высокоскоростной сетке другого-то подхода и не используют.
Можно я сделаю вид, что и сам не понимаю — а как же так могло получиться-то? ))


V>>Когда данные из разогретой базы достаются прямиком из оперативки (а таких будет 99.99% случаев в тех самых нагруженных сценариях), то они достаются за единицы/десятки микросекунд.
S>Да-да, я помню. И данных про то, сколько занимает разбор запроса и формирование ответа как не было так и нет.

Так вычти одно из другого, какие проблемы?
Получишь разницу.
Там до порядка разница в нормальном режиме работы, т.е. вот уже биржа стартовала и пошла разгребать чудовищный трафик событий — т.е. база уже через секунды будет хорошо "разогрета" и такой и будет оставаться до конца рабочего дня.



V>>Причём, коллега проявляет удивительную настойчивость в нежелении продвигаться.
S>Продвигаться некуда. Вы, коллега, традиционно избегаете упоминания любых технических деталей, отделываясь бессмысленными намёками.

Вот почему вместо того, чтобы честно признаться в недостатке воображения, в неспособности увидеть отличия м/у сценариями статической и динамической типизации, надо обязательно искать виноватых на стороне?

Я пока мест жду, пока у тебя в голове что-то щелкнёт и ты начнёшь сам себя останавливать в своих аргументах, по принципу: "ан нет, аргумент не годный, там же статика". И начнёшь думать на шажок дальше. И тогда сам характер твоих вопросов поменяется на примерно такие: "а как в статике делать то-то и то-то", т.е. я сразу увижу, что разговариваю с осмысленным собеседником, а не лишь бы ля-ля-ля.


S>Как я уже говорил, эта манера беседы прекрасно подходит для охмурения первокурсниц ИТ-специальностей.

Пока что ты даже и не начинал включать голову, чтобы отстреливаться шаблонными фразами.
Не заслужил ты пока шаблонности в этом споре.
Попробуй еще раз.
Или тупо забей, если накатила лень ума.