![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://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 (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
Цель - не "сгенерить по имеющимся классам какую-то базу и какой-то ДАО". Получится херня.
Должна нормально вдумчиво проектироваться база, под нее писаться на ОРМе прослойка. Цель прослойки - упрощение работы с базой и простота будушего рефакторинга. Но мозг это не отменяет, и то, что он генерирует, нужно смотреть глазами.
no subject
И вообще, толщина прослойки начинается от нуля.
no subject
В результате создание слоя для работы с СУБД у меня занимает весьма мало времени по сравнению с другими методами. И причем я сразу получаю код который могу отдать другому человеку.
no subject
Моей программке начиная от первых версий лет наверное 15 уже, можете прикинуть как часто мне приходится писать новые привязки к полям.
Каждому инструменту - свое место.
no subject
У вас наверное проблема в том что кодинг занимает много времени. Вы наверное делаете по приложению в неделю. Может быть да, в вашем случае выпекание пирожков на потоке имеет смысл.
У меня проблема в том что требуется быстрый старт и быстрые изменения. При этом я хочу сконцентрироваться на самом приложении и как оно работает, а не слое работы с СУБД. Если бы вы использовали такой же инструментарий, то ваше ПО развивалось быстрее и вы меньше тратили бы времени на нудное программирование работы приложения с СУБД.
no subject
no subject
no subject
У меня старт был давным-давно, сейчас просто эволюция вместе с бизнесом.
no subject
После быстрого старта бывают проблемы с медленным развитием когда этот быстрый старт надо перепроектировать.
Узнайте для себя такую вещь как слабая связность. И быстрый старт тут касается не проектирования, а написания кода.
no subject
no subject
>>"FactoryOfFactoryOfFactoryOfFacade"
Слишком утрированно
no subject
После нормальных языков с нормальными типами и метапрограммированием это все выглядит, как попытка любой ценой соблюсти обратную совместимость и не отпугнуть индусов из бангалора.
Похвальное желание, с точки зрения организации процессов разработки, но адекватные разработчики получившееся творчество будут избегать любой ценой.
no subject
no subject
Как и мне приходится писать на всякой хреновой чуши, по причине того, что миграция на адекватные языки требует невменяемых усилий.
no subject
no subject
Генерите ОРМ по базе? Или как?
no subject
no subject
no subject
no subject