Здравствуйте, vdimas, Вы писали:
V>Слабовато с воображением.
Сочувствую.

V>А сколько всего может быть вариантов плана у среднего запроса?
V>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
Это зависит от того, какую степень независимости клиента от сервера мы ожидаем.
То, что для клиента выглядит как простой select top * from ... на "той стороне" может превратиться в весьма разветвлённый запрос по нескольким физическим хранилищам и прочее.
И там вариантов плана будут десятки и сотни.
Но это не важно — даже если вариантов всего два, у клиента нет способа правильно выбрать тот из них, который эффективнее для конкретных параметров с конкретным наполнением данными.

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

V>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
А, ну это отличная идея. Не факт, правда, что работоспособная.
Вот в качестве ближайшего примера — в моей конторе есть специальный сервер, куда каждая из инсталляций продукта сообщает статистику использования. Написан лет 10 назад, последние новости туда закоммитили году в 2012м, что ли.
"все запросы" там уже есть — штук пять веб-страничек, которые должны реализовывать все потребности клиентов.
Тем не менее, лично мои потребности эти прошитые запросы не удовлетворяют. Приходится писать скрипты, которые вытаскивают данные на клиента, и надругаются над ними уже локально.
Это показывает не то, насколько я крут в хтмл-скраппинге, а то, что все варианты запросов предусмотреть трудно.

V>По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
Тут ключ к успеху — не нагрузка, а то, что все виды запросов, действительно, зафиксированы раз и навсегда. На бирже, я думаю, с 16 века мало что изменилось.
Поэтому можно себе позволить скомпилировать клиента вместе с сервером и забить на развитие.
И планы запросов можно прописать раз и навсегда. Роскошь, чё.
Увы — в этот класс приложений попадает очень мало всего. Тот же "банкинг" на самом деле устроен совсем не так, как во влажных мечтах С++ программистов. Там как раз SQL, адская Java, и прочие тормоза на ровном месте.
А чего вы хотели, когда реал-тайм банкинг — это выполнение перевода в течение 4х часов минимум (а SLA — вообще 2 банковских дня).
V>Иначе мы ведем разговор не о статике, а не понятно о какой химере, которую ты себе вообразил. ))
Ну вот теперь мы говорим о чём-то предметном — о приложениях, где объём функционала — с гулькин хрен, а стоимость потери времени — высока. То есть — о биржах.

V>Классный залёт.
V>"Это" становится известным в рантайм, а не компайл-тайм.
И слава байту. Иначе у нас первое же обновление сервера убьёт всех клиентов из-за несовместимости протокола.
V>Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
Ага. А также ещё на 100500 мусора, который не имеет отношения к теме разговора.
V>Наверно тем лучше, что в высокоскоростной сетке другого-то подхода и не используют.
Ну, то есть данных нет. Просто "ну, наверное там ребята разобрались". Можно было так и сказать, а не выделываться, намекая на какое-то сакральное знание, которым вы обладаете, а все остальные — неучи.

V>Так вычти одно из другого, какие проблемы?
Что из чего вычитать? Ну, для "базы", которая на бирже крошечная и с примитивной структурой, данные есть. Правда, непонятно, каким образом биржа ухитряется выполнять коммит транзакции без записи на диск — там ведь никак не получатся ни единицы, ни десятки микросекунд. А сколько бы времени тратила эта же биржа на парсинг строки, если бы ей запрос приезжал в виде SQL? Пикосекунду?

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

V>Или тупо забей, если накатила лень ума.
Это не лень ума, а разумный скепсис. Пока что он полностью подтверждается — внезапно оказывается, что предметом беседы стал не универсальный язык по доступу и манипуляции реляционными данными, а написание узкоспециализированных решений вроде бирж или телекоммуникаций. Ну вот в телекомах накат новых решений называется "развёртывание сетей нового поколения" и занимает годы. А убогий SQL в трёхзвенках позволяет выпускать обновления приложений еженедельно.

Нет, меня тоже лет 20 тому назад потрясло то, что за время, которое SQL Server тратит на выполнение одного запроса, локальное приложение "база телефонных номеров и адресов города Новосибирска" ухитряется поднять в память всю базу и найти ответ. Вот она — чудовищная сила статики! Код вместе со схемой данных, а схема — это прямое отображение атрибутов на смещения. В однопользовательском режиме, да ещё и при декомпрессии на лету — красота производительности. Угу. Однако все мы знаем, почему в многопользовательской среде клиппером пользоваться перестали, а перешли таки на MS SQL, Oracle, и прочие интербейзы.