![[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-04 08:02 am (UTC)Извините, что влезаю в ваш диалог, но судя по анимешному фейсу на вашей аватарке, вы относитесь к более молодому поколению. И у вас с оппонентов разный опыт разработки.
Когда пишешь на стороннего дядю - начинают вылазить странные требования, вроде .NET, кроссплатформенности, включающей FreeBSD, WinXP 64bit и проблемы наподобие "у нас бухгалтерия не может это провести, переделайте".
Когда работаешь со своим предприятием, то бухаглтерия делает то, что ей сказано, несовместимые компьютеры с неподдерживаемыми ОС просто не покупаются, и вообще - большая часть вопросов решается административно. И вообще, пространство для маневра намного шире.
no subject
Date: 2013-04-04 08:08 am (UTC)Когда работаешь со своим предприятием
Когда работаешь со своим предприятием возникает "надо вчера". И использование фреймворков и орм дает больше времени для маневра. Тупо за счет меньшего внимания к рутинным операциям и тому а как бы сделать тут так чтоб у меня архитектуру не скрючило.
no subject
Date: 2013-04-04 08:19 am (UTC)1) Не софтовая.
2) Ваша.
Очень сомнительно, чтобы у некой торговой компании возникла необходимость "ко вчера" что-то переделать.
no subject
Date: 2013-04-04 08:22 am (UTC)