![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclasshttp://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 (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-04-03 01:53 pm (UTC)На SQL оптимизация выполняется в процессе написания, и гавно видно сразу, кроме кривых планов на возросших данных.
Ну рассказывайте, рассказывайте. Что ни разу индекс не забывали?
А на ОРМ приложив усилие можно тоже написать гладко, но по дефолту легко получить гавно и не заметить этого.
На ORM не надо прикладывать усилий чтобы написать гладко. Там точно так же как и в случае SQL мы знаем тут будет много надо сразу сделать оптимизацию. Опять же такая оптимизация туда вносится ровно так же как и в SQL. У меня есть большой проект на ORM JPA и если бы я использовал SQL то усилий я бы затрачивал местами даже больше. Так-как местами пришлось бы выкручиваться а тут как а там как.
no subject
Date: 2013-04-03 05:12 pm (UTC)Честно говоря не пойму про что вы говорите, где и как можно забыть индекс.
Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.
Где тут можно забыть индекс?
no subject
Date: 2013-04-03 05:28 pm (UTC)Честно говоря не пойму про что вы говорите, где и как можно забыть индекс.
Да очень просто. На момент проектирования предполагалось что тут данных будет мало. А потом внезапно план выполнения запроса посмотрели опаньки, а их тут много.
Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.
Учтивая характер того как вы разрабатываете, не удивительно. Но такая скорость разработки для любого другого софта просто не приемлема. Как правило фича нужна не через месяц как разработчик насладится игранием в explain и его адаптацией к конкретной ситуации, а завтра. В этом случае есть время выработать внятные подходы со слабой связностью. Чтобы в случае чего было просто это переделать. Но это же хотя и позволяет делать ошибки, но позволяет так же исправлять их просто и быстро.
no subject
Date: 2013-04-03 05:38 pm (UTC)Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.
Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".
no subject
Date: 2013-04-03 05:52 pm (UTC)Какой месяц на explain, каких данных мало?
Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.
Далеко не всегда :) Иногда есть проблема вида надо вчера. Плюс изначально при постановке предполагался меньший поток данных, а фактически получили больший. Плюс можно поймать баг explain использует не тот индекс. Я такое на PostgreSQL ловил. Лечилось отстрелом индекса как это не парадоксально.
Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".
Конкретно надо по месту смотреть что там будет. И старательно бить канделябром за забрали 100500 объектов.
no subject
Date: 2013-04-04 12:51 am (UTC)А если нужен но мешает вот в этом конкретном запросе - то его можно отключить конструкциями типа "+0", правда я не в курсе работает ли этот хак на постгресе.
Базы у меня гигабайтные, поэтому уже никаких "внезапно отросших данных" давно не наблюдаю, и тестировать есть на чем.
no subject
Date: 2013-04-04 12:55 am (UTC)А если нужен но мешает вот в этом конкретном запросе - то его можно отключить конструкциями типа "+0", правда я не в курсе работает ли этот хак на постгресе.
Нет хинтов в PostgreSQL. А индекс был добавлен еще давно и как раз было внезапно много данных.
Базы у меня гигабайтные, поэтому уже никаких "внезапно отросших данных" давно не наблюдаю, и тестировать есть на чем.
То что у вас все хорошо тут уже все поняли и я сильно сочувствую тем кто будет переделывать систему после вас.
no subject
Date: 2013-04-04 01:13 am (UTC)>> правда я не в курсе работает ли этот хак на постгресе.
>>>> Нет хинтов в 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
Date: 2013-04-04 02:15 am (UTC)Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Была другая выборка.
В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.
Фишка в том что иногда вы не можете предсказать какие там данные будут. Только предположить и эти предположения могут быть ошибочны.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2013-04-07 06:29 am (UTC)no subject
Date: 2013-04-07 12:45 pm (UTC)Если вас размерчик не устраивает - ничем не могу помочь.
no subject
Date: 2013-04-03 06:01 pm (UTC)Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%
ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.
Что такое "разработчик насладится игранием в explain и его адаптацией к конкретной ситуации" - я не понял.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.
Планы запроса от количества записей у меня вроде не менялись ни разу, ну или может пару раз за 15 лет. А вот при смене версии сервера головняков было побольше - и смена планов из-за изменения в оптимизаторе и необходимость переименовки некоторых полей которые стали совпадать с ключевыми словами сервера.
no subject
Date: 2013-04-03 06:15 pm (UTC)Вы как-то странно делаете вывод о моей скорости из описания процесса.
Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%
ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.
Он поможет в 40 процентах. Так-как написание запросов может и не потребоваться.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
Вы бы про MVC почитали уже. Вы видимо даже как-то не в курсе что в случае ORM форма это и есть объект с данными.
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Для crud операций? А смысл?
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.
Вы видимо меня плохо понимаете. У меня проектирование начинается с БД, а потом по ней генерится слой для работы с ней. В результате я сразу могу переходить к разработке приложения, в том числе минуя стадию отладить запрос вот для этой штуки. Когда таких запросов надо отладить больше 10 это мягко говоря утомительно и однообразно.
Планы запроса от количества записей у меня вроде не менялись ни разу, ну или может пару раз за 15 лет. А вот при смене версии сервера головняков было побольше - и смена планов из-за изменения в оптимизаторе и необходимость переименовки некоторых полей которые стали совпадать с ключевыми словами сервера.
У меня складывается ощущение, что в вашу программу изменения вносятся раз в пятилетку. При таком подходе работает какой угодно метод программирования.
no subject
Date: 2013-04-03 06:22 pm (UTC)Запрос select * from table в отладке не нуждается, а иных у вас после генерации и не будет.
no subject
Date: 2013-04-04 12:22 am (UTC)no subject
Date: 2013-04-03 07:01 pm (UTC)no subject
Date: 2013-04-03 06:06 pm (UTC)а, ещё и файрбёрд. атлична атлична. сразу было понятно что тупой мудак типа уёбищного крокодила, а тут ещё и столько подтверждений сразу.
no subject
Date: 2013-04-03 06:22 pm (UTC)no subject
Date: 2013-04-03 06:26 pm (UTC)no subject
Date: 2013-04-03 06:39 pm (UTC)no subject
Date: 2013-04-03 06:48 pm (UTC)http://metaclass.livejournal.com/800013.html?thread=17316365&style=mine#t17316365
такое у тебя тоже есть?
no subject
Date: 2013-04-04 02:32 am (UTC)no subject
Date: 2013-04-04 02:34 am (UTC)no subject
Date: 2013-04-04 05:46 am (UTC)Firebird - по причине упоротого комьюнити, мелких недостатков в обслуживании и общей ненависти ИТ-сообщества к нему.