SQL

tarasv> ORM это тупик для любого более менее нагруженного приложения. Их применение оправдано только тем что они позволяют выкатить MVP достаточно быстро. Не взлетело - выкинули и забыли, но если взлетело то это надо срочно переписывать, как минимум R в CRUD.
Есть два основных подхода в создании приложений - Database Centric, те ориентированных на базу и Application Centric, т.е. ориентированных на приложение.
ORM это AС, для которого база это просто хранилище ( Storage ).
Code First ( С# ) или хибирнейты ( Java ) - это оттуда.
Да, там все через некоторое время все начинает тормозить. Все красиво пока данных мало.
Причем индексы в Code First описываются так же на шарпе

А я говорил, применительно к скомпилированному плану, про DC - разумеется мой любимый подход.
Тогда приложение можно сделать компактным, но оно изолировано от структуры БД - ему дают что дают.

Я как-то еще давно писал в подобном подходе на двоих с мужиком администратор для прикладной БД.
Так вот он динамически загружался с базы - в ней была описана как система меню, так и набор форм и набор контролов для формы и их обработчики ( разумеется на стороне базы ).

Т.е. приложение при старте по факту имело только данные о базе к которой надо подключится.
Далее оно развертывало свой функционал с базы - строило систему меню и создавало формы по описанию и привязывало обработчики на кнопки.

Код приложения был очень компактный.

16-й> Если бы. С нынешними оптимизаторами, затюнингованными по самые помидоры, все спортивно. Чуть дал ты маху при конфигурировании с оценкой, скажем, многоблочного чтения, и oracle тебе напихает в сложный запрос кучу декартовых произведений там где не просили.
Не скажу про оракл, но MS SQL я декартов редко вижу - т.е. либо толстый хэш матч либо table spool

Понятно отчего это возникает в сложных запросах ?

yacc> Понятно отчего это возникает в сложных запросах ?

Если он начинает недооценивать многоблочное чтение, то мнит себе, что лучше сначала (полдня потерять) сделать full scan и cartesian на малых входах, а потом (за пять минут долететь) через merge join. Вот прямо переклинивает его иногда. Особенно, когда любители этого дела, мастерят вью, потом вью на вью, и т.д., а потом в конечном селекте условие отбора, которое не пропихивается вниз.

yacc>> Понятно отчего это возникает в сложных запросах ?
16-й> Если он начинает недооценивать многоблочное чтение, то мнит себе, что лучше сначала (полдня потерять) сделать full scan и cartesian на малых входах, а потом (за пять минут долететь) через merge join. Вот прямо переклинивает его иногда. Особенно, когда любители этого дела, мастерят вью, потом вью на вью, и т.д., а потом в конечном селекте условие отбора, которое не пропихивается вниз.

а без вьюх ты никуда если мы про ентерпрайз кроваваый.

во первых они слой физики маскируют от приклада на случай изменения физ модели в процессе ЖЦ базы.
во вторых доступы...разным пользюкам - разные вьюхи с разными грантами.

yacc>> Понятно отчего это возникает в сложных запросах ?
16-й> Если он начинает недооценивать многоблочное чтение, то мнит себе, что лучше сначала (полдня потерять) сделать full scan и cartesian на малых входах, а потом (за пять минут долететь) через merge join.
Потому что алгоритм СУБД строит план основываясь на кардинальности, которую "по-верхам" - т.е. по статистике и гистограммам оценить сложно ( реально сложно ), если план развесистый.
Более того выбор оптимального плана ограничен - если оптимизатор видит что ниже план имеет большую цену, то это ветку он далее не рассматривает. Хотя именно там ниже может быть именно оптимальный план.

16-й>Особенно, когда любители этого дела, мастерят вью, потом вью на вью, и т.д., а потом в конечном селекте условие отбора, которое не пропихивается вниз.
Угу - именно на таких запросах оптимизатор лажает влегкую

с.т.> а без вьюх ты никуда если мы про ентерпрайз кроваваый.
Тут речь про другое - когда более сложный вопрос комбинируется из существующих представлений
Т.е. у тебя есть CREATE VIEW которое по канонам в нужной схеме с нужным доступом
... но делаешь ты его из других VIEW вместо того, чтобы написать через таблицы

Т.е. по крупноблочному.

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

yacc> А я говорил, применительно к скомпилированному плану, про DC - разумеется мой любимый подход.

Допустим у нас есть план запроса сохраненный в виде исполняемого кода. Он не изменен все время жизни приложения. Но тогда он будет оптимален только для того набора данных в БД на котором он был получен. И есть вероятность потерять производительность на других данных. Чтобы иметь предсказуемое время исполнения такой план не должен использовать статистику, а строится только на структуре БД. Это мне живо напоминает ORM которые игнорируют возможности СУБД и используют их чуть ли не как KV store с транзакциями. Сохраненный план безусловно оптимизирует время выполнения коротких тривиальных запросов, когда время исполнения близко к времени построения плана. Но только в случае если в СУБД планы не кэшируется. А они кэшируется во многих СУБД.
Более сложные запросы, в которых наличие статистики важно для построения оптимального плана, скорее всего будет выполняться медленнее. В таких запросах время на построение плана обычно многократно меньше времени выполнения, часто на порядки. Где выигрыш тут?

yacc> Тогда приложение можно сделать компактным, но оно изолировано от структуры БД - ему дают что дают.

Так сохраненный запрос или abstract db layer? Abstract db layer вполне почтенный подход, с ним главное не наплодить абстракций больше меры.

yacc> Код приложения был очень компактный.

Хранение конфигурации в db это уже третье. Это хорошо когда нужно несколько однотипных приложений, а плохо то что в BD не дает надежного версионирования что часто создает дикую головную боль в troubleshooting. Если у меня приложение build XYZ то я знаю с чем имею дело, а если в базе написано что она версии ZYX то есть ненулевая вероятность что, на самом деле, она не то чем претворяется.

tarasv> Но тогда он будет оптимален только для того набора данных в БД на котором он был получен.

Мало того, по нынешней моде, он будет оптимален и для тех условий отбора, которые были использованы при в запросе, когда ему план строили. И даже без всяких констант в комиссарском теле. Bind peeking и всякое тому подобное.
Оптимизатор в СУБД это ее чуть ли не основная фишка, как сиськи у барышни. Замещать действие оптимизатора чем-то на стороне, это почти гейство.

tarasv> Но тогда он будет оптимален только для того набора данных в БД на котором он был получен.
Плюс-минус.
Не только для этого набора.
Но в самом общем виде - на произвольных данных - он не будет всегда оптимальным.

tarasv> Это мне живо напоминает ORM которые игнорируют возможности СУБД и используют их чуть ли не как KV store с транзакциями.
Принципиальное отличие ORM что оно само не генерирует индексы, а тем более на лету.

tarasv> В таких запросах время на построение плана обычно многократно меньше времени выполнения, часто на порядки. Где выигрыш тут?
Я и не предлагаю это решение для запросов в самом общем виде.
Как я и говорил - если данные многократно превышают объем ОЗУ - смысла в таком нет - там физическое чтение будет основным затыком в производительности.
Мое приближение имеет смысл на малых однопользовательских базах типа SQLite

tarasv> Так сохраненный запрос или abstract db layer? Abstract db layer вполне почтенный подход, с ним главное не наплодить абстракций больше меры.
В терминах ядра БД это называется так - "дерево исполнения физического плана"

tarasv> Хранение конфигурации в db это уже третье. Это хорошо когда нужно несколько однотипных приложений, а плохо то что в BD не дает надежного версионирования
Это делается внешними средствами через скрипты и версионированием скриптов, плюс таблицу версий.

16-й> Оптимизатор в СУБД это ее чуть ли не основная фишка, как сиськи у барышни. Замещать действие оптимизатора чем-то на стороне, это почти гейство.
Очевидно что речь идет про малые базы.

Оптимизатор SQLite - не такой навороченный.

Если приложение использует данные больше чем размер ОЗУ - ну там создает контейнер с массивом объектов, суммарный объем которых выходит за ОЗУ - то оно получит ... своп и тормоза.
Не... тебе дадут возможность выделить динамически память сверх ОЗУ, но тормознутым путем

tarasv>> Это мне живо напоминает ORM которые игнорируют возможности СУБД и используют их чуть ли не как KV store с транзакциями.
yacc> Принципиальное отличие ORM что оно само не генерирует индексы, а тем более на лету.

Да они всю схему норовят сгенерировать. И индексы в том числе. Но это конечно болванка которую потом опиливать надо.

yacc> Мое приближение имеет смысл на малых однопользовательских базах типа SQLite

Теперь понял. Для такого вполне применимо.

yacc> Это делается внешними средствами через скрипты и версионированием скриптов, плюс таблицу версий.

Есть это все и Liquibase в придачу. Но это не дает гарантии от безалаберности DBA и установщиков или патчей по живому руками разработчиков тушащих возгорание. Проверено личным опытом.

tarasv> Да они всю схему норовят сгенерировать. И индексы в том числе. Но это конечно болванка которую потом опиливать надо.
В том то и дело, что индексы не по запросам

yacc>> Мое приближение имеет смысл на малых однопользовательских базах типа SQLite
tarasv> Теперь понял. Для такого вполне применимо.
Ясен пень что к большим СУБД это вообще не надо - там сервер лучше справится

tarasv> Есть это все и Liquibase в придачу. Но это не дает гарантии от безалаберности DBA и установщиков или патчей по живому руками разработчиков тушащих возгорание. Проверено личным опытом.
Безалаберность бывает всегда
Проверено личным опытом