![[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 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)