![[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 07:27 pm (UTC)Тут такое дело - промежуточные данные для отчетности идеально делаются sql запросами. Неважно, в 10 строк или в 100 - ключевой момент, что в схеме БД не создаются новые объекты для таких запросов (их очень неудобно поддерживать).
Но постобработка - лучше это делать на clojure. Например, когда надо 150 кодов аналитики разложить по нетривиальным правилам в 30 пунктов итогового отчета. Я раньше это делал на императивных расширениях SQL - поддержка задалбывает (отладки нет, проверка ошибок через задницу, контроль версий аналогично).
Далее - удобнее завернуть это дело в json на clojure и отдать клиенту (десктопному приложению и js-клиенту) чем отдавать нативным протоколом СУБД клиентской либе этой же СУБД.
no subject
Date: 2013-04-03 07:48 pm (UTC)Да, это я понимаю. Плодить отдельный ad-hoc тип под каждую процедуру, которая вызывается снаружи сервера и которой типы этого сервера до лампочки, как-то глуповато.
отладки нет
В постгресе можно писать в лог оператором raise, а что еще надо? Интерактивного дебаггера и в clojure наверное нет, да и нужен ли он вообще?
контроль версий аналогично
Для хранимых процедур никаких проблем нет, а для таблиц - так тут все равно clojure или plsql.
отдавать нативным протоколом СУБД клиентской либе этой же СУБД
Согласен. В постгресе сейчас можно вложенные данные как json отдавать, но это не очень удобно. На мой взгляд, если бы в pg сделали cursor expressions, как в оракле, то девелоперу больше не о чем было бы и мечтать - все есть.