![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
Честно говоря не пойму про что вы говорите, где и как можно забыть индекс.
Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.
Где тут можно забыть индекс?
no subject
Честно говоря не пойму про что вы говорите, где и как можно забыть индекс.
Да очень просто. На момент проектирования предполагалось что тут данных будет мало. А потом внезапно план выполнения запроса посмотрели опаньки, а их тут много.
Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.
Учтивая характер того как вы разрабатываете, не удивительно. Но такая скорость разработки для любого другого софта просто не приемлема. Как правило фича нужна не через месяц как разработчик насладится игранием в explain и его адаптацией к конкретной ситуации, а завтра. В этом случае есть время выработать внятные подходы со слабой связностью. Чтобы в случае чего было просто это переделать. Но это же хотя и позволяет делать ошибки, но позволяет так же исправлять их просто и быстро.
no subject
Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.
Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".
no subject
Какой месяц на explain, каких данных мало?
Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.
Далеко не всегда :) Иногда есть проблема вида надо вчера. Плюс изначально при постановке предполагался меньший поток данных, а фактически получили больший. Плюс можно поймать баг explain использует не тот индекс. Я такое на PostgreSQL ловил. Лечилось отстрелом индекса как это не парадоксально.
Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".
Конкретно надо по месту смотреть что там будет. И старательно бить канделябром за забрали 100500 объектов.
no subject
А если нужен но мешает вот в этом конкретном запросе - то его можно отключить конструкциями типа "+0", правда я не в курсе работает ли этот хак на постгресе.
Базы у меня гигабайтные, поэтому уже никаких "внезапно отросших данных" давно не наблюдаю, и тестировать есть на чем.
no subject
А если нужен но мешает вот в этом конкретном запросе - то его можно отключить конструкциями типа "+0", правда я не в курсе работает ли этот хак на постгресе.
Нет хинтов в PostgreSQL. А индекс был добавлен еще давно и как раз было внезапно много данных.
Базы у меня гигабайтные, поэтому уже никаких "внезапно отросших данных" давно не наблюдаю, и тестировать есть на чем.
То что у вас все хорошо тут уже все поняли и я сильно сочувствую тем кто будет переделывать систему после вас.
no subject
>> правда я не в курсе работает ли этот хак на постгресе.
>>>> Нет хинтов в PostgreSQL. А индекс был добавлен еще давно и как раз было внезапно много данных.
Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Я не советовал пользоваться хинтами.
Если упрощенно то
select id, name from table where id = 10
заюзает индекс по ID.
Но если запрос написать в виде
select id + 0 as id, name from table where id = 10
то индекс по ID уже использоваться не будет.
Далее надеюсь понятно как можно отключать индексы.
Повторю - это в Firebird есть такая особенность оптимизатора. Сработает ли это в PG - не в курсе.
Почитал про EXPLAIN - оказалось что это план запроса так называется в PG.
В Firebird оптимизатор поплоше чем в PG будет, но даже и в PG засады случаются, поэтому при написании запроса, если хоть сколько-то интересуют перспективы работы - просмотр получаемого плана обязателен.
В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.
no subject
Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Была другая выборка.
В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.
Фишка в том что иногда вы не можете предсказать какие там данные будут. Только предположить и эти предположения могут быть ошибочны.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
Если вас размерчик не устраивает - ничем не могу помочь.
no subject
Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%
ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.
Что такое "разработчик насладится игранием в explain и его адаптацией к конкретной ситуации" - я не понял.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.
Планы запроса от количества записей у меня вроде не менялись ни разу, ну или может пару раз за 15 лет. А вот при смене версии сервера головняков было побольше - и смена планов из-за изменения в оптимизаторе и необходимость переименовки некоторых полей которые стали совпадать с ключевыми словами сервера.
no subject
Вы как-то странно делаете вывод о моей скорости из описания процесса.
Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%
ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.
Он поможет в 40 процентах. Так-как написание запросов может и не потребоваться.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
Вы бы про MVC почитали уже. Вы видимо даже как-то не в курсе что в случае ORM форма это и есть объект с данными.
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Для crud операций? А смысл?
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.
Вы видимо меня плохо понимаете. У меня проектирование начинается с БД, а потом по ней генерится слой для работы с ней. В результате я сразу могу переходить к разработке приложения, в том числе минуя стадию отладить запрос вот для этой штуки. Когда таких запросов надо отладить больше 10 это мягко говоря утомительно и однообразно.
Планы запроса от количества записей у меня вроде не менялись ни разу, ну или может пару раз за 15 лет. А вот при смене версии сервера головняков было побольше - и смена планов из-за изменения в оптимизаторе и необходимость переименовки некоторых полей которые стали совпадать с ключевыми словами сервера.
У меня складывается ощущение, что в вашу программу изменения вносятся раз в пятилетку. При таком подходе работает какой угодно метод программирования.
no subject
Запрос select * from table в отладке не нуждается, а иных у вас после генерации и не будет.
no subject
no subject
no subject
а, ещё и файрбёрд. атлична атлична. сразу было понятно что тупой мудак типа уёбищного крокодила, а тут ещё и столько подтверждений сразу.
no subject
no subject
no subject
no subject
http://metaclass.livejournal.com/800013.html?thread=17316365&style=mine#t17316365
такое у тебя тоже есть?
no subject
no subject
no subject
Firebird - по причине упоротого комьюнити, мелких недостатков в обслуживании и общей ненависти ИТ-сообщества к нему.