![[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:03 am (UTC)И вообще, толщина прослойки начинается от нуля.
no subject
Date: 2013-04-03 03:59 pm (UTC)В результате создание слоя для работы с СУБД у меня занимает весьма мало времени по сравнению с другими методами. И причем я сразу получаю код который могу отдать другому человеку.
no subject
Date: 2013-04-03 04:27 pm (UTC)Моей программке начиная от первых версий лет наверное 15 уже, можете прикинуть как часто мне приходится писать новые привязки к полям.
Каждому инструменту - свое место.
no subject
Date: 2013-04-03 05:21 pm (UTC)У вас наверное проблема в том что кодинг занимает много времени. Вы наверное делаете по приложению в неделю. Может быть да, в вашем случае выпекание пирожков на потоке имеет смысл.
У меня проблема в том что требуется быстрый старт и быстрые изменения. При этом я хочу сконцентрироваться на самом приложении и как оно работает, а не слое работы с СУБД. Если бы вы использовали такой же инструментарий, то ваше ПО развивалось быстрее и вы меньше тратили бы времени на нудное программирование работы приложения с СУБД.
no subject
Date: 2013-04-03 06:02 pm (UTC)no subject
Date: 2013-04-03 06:09 pm (UTC)no subject
Date: 2013-04-03 06:03 pm (UTC)У меня старт был давным-давно, сейчас просто эволюция вместе с бизнесом.
no subject
Date: 2013-04-03 06:08 pm (UTC)После быстрого старта бывают проблемы с медленным развитием когда этот быстрый старт надо перепроектировать.
Узнайте для себя такую вещь как слабая связность. И быстрый старт тут касается не проектирования, а написания кода.
no subject
Date: 2013-04-03 06:17 pm (UTC)no subject
Date: 2013-04-03 08:17 pm (UTC)>>"FactoryOfFactoryOfFactoryOfFacade"
Слишком утрированно
no subject
Date: 2013-04-03 08:41 pm (UTC)После нормальных языков с нормальными типами и метапрограммированием это все выглядит, как попытка любой ценой соблюсти обратную совместимость и не отпугнуть индусов из бангалора.
Похвальное желание, с точки зрения организации процессов разработки, но адекватные разработчики получившееся творчество будут избегать любой ценой.
no subject
Date: 2013-04-03 08:44 pm (UTC)no subject
Date: 2013-04-03 08:46 pm (UTC)Как и мне приходится писать на всякой хреновой чуши, по причине того, что миграция на адекватные языки требует невменяемых усилий.
no subject
Date: 2013-04-04 12:21 am (UTC)no subject
Date: 2013-04-03 05:20 pm (UTC)Генерите ОРМ по базе? Или как?
no subject
Date: 2013-04-03 05:24 pm (UTC)no subject
Date: 2013-04-03 05:32 pm (UTC)no subject
Date: 2013-04-03 05:37 pm (UTC)no subject
Date: 2013-04-03 08:20 pm (UTC)