![[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 04:44 am (UTC)Мои прокладки написаны в минималистичном стиле, делают только то что надо мне, их изучить по исходникам гораздо проще чем ваши ОРМ и прочие фреймворки.
Не проще. У вас нет документации. Никто в здравом смысле сейчас не изучает фреймворки и ОРМ по исходникам. А уж с ORM и framework это сделать проще из-за наличия документации и описания общей идеологии. И что еще лучше я могу найти программиста с опытом работы и с нужным мне ORM и с фреймворком и мне надо будет ему рассказать только особенности нашего ПО, а не наших инструментов. Да и в случае если человек их не знает, но толков, я могу его отправить в документацию по ORM и фреймворку и не тратить на это свое время.
Остальной код кроме моих прокладок выглядит как из букваря - тут кроме паскаля и прикладной задачи ничего знать и не потребуется.
Конечно конечно.
Мои велосипеды создавались когда вашего супермейнстрима еще не существовало.
Это какого же года ваши велосипеды? Первая стабильная версия Spring Framework вышла в 2004 году. Про JEE я уже вообще молчу первая редакция 1999 год.
По поводу сопровождения после меня - думаю что это просто не потребуется.
Все верно. Его просто выкинут.
"Универсальный решатель всего" и "вечно живущая программа" - это бессмысленные утопии. Все имеет свой цикл жизни, программы в том числе.
Про вечно живущие программы речи не идет. Речь идет о соответствии реалиям.
no subject
Date: 2013-04-04 05:56 am (UTC)Не знаю, мне в исходники чужого жабокода приходится лазить регулярно.
J2EE использовать в мелких проектах, поддерживаемых одной конторой - смысла никакого нет. Впрочем, его вообще нет смысла использовать, это дрочево на паттерны и хымыль.
Тут такое дело, что лучше взять адекватный язык и использовать его ORM (http://slick.typesafe.com/), потому что там кода просто на порядок меньше. Язык не требует стоять на голове, чтобы сделать что-либо.
no subject
Date: 2013-04-04 06:01 am (UTC)Не знаю, мне в исходники чужого жабокода приходится лазить регулярно.
Я лазил один раз, мне требовалось понять как делать свои view.
J2EE использовать в мелких проектах, поддерживаемых одной конторой - смысла никакого нет. Впрочем, его вообще нет смысла использовать, это дрочево на паттерны и хымыль.
Новый уже можно, там такого пиздеца с xml не наблюдается уже. Ну или Play! иди Spring Framework. Это дело вкуса. Можно вообще прости господи php если что мелкое надо.
Ну а на другие языки я поглядываю периодически, что в болоте с java не сидеть :]