В Советской Белоруссии SQL разжигает айседа

[metaclass]

http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.

Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).

Comments

[norguhtar.livejournal.com]

Ну извиняйте, но людям нужны более простые интерфейсы. А то так выяснится что во имя передвижения мы вместо того чтобы ходить ногами ездим на весьма сложном с технической стороны автомобиле.

[norguhtar.livejournal.com]

Ну извиняйте, но людям нужны более простые интерфейсы. А то так выяснится что во имя передвижения мы вместо того чтобы ходить ногами ездим на весьма сложном с технической стороны автомобиле.

[norguhtar.livejournal.com]

А какие варианты? Закат солнца в ручную? Нет спасибо, я лучше с ORM поработаю.

[fraks-nsk.livejournal.com]

В каком месте ОРМ стал проще чем без него?

[fraks-nsk.livejournal.com]

Конкретное решение чего?
Ответ зависит от задачи, от решающего эту задачу. У разных решающих могут быть разные решения с одинаковым результатом.

[fraks-nsk.livejournal.com]

гибернейт сгенерирует только простые запросы которые подразумевают что БД это тупое хранилище.
Нередко гораздо эффективней написать процедуру или execute block с выполнением кода на сервере чем тащить это на клиента и там распихивать по объектам ОРМ и уже по ним елозить, как когда-то по DBF табличкам. Да, так и при ОРМ можно сделать, но он тут будет только мешать.

[fraks-nsk.livejournal.com]

Вы не путайте людей которые пользуются софтиной с людьми которые эту софтину пишут.

[norguhtar.livejournal.com]

У вас был софт с превалированием CRUD операций? Это там где есть оператор и он что-то заносит в базу.

[fraks-nsk.livejournal.com]

Не только был но и есть. Я классический складописатель :)

[norguhtar.livejournal.com]

Давайте начнем с начала. Вы пришли и сказали ORM говно и что он закат солнца в ручную 1.5-2 раза. А теперь вы мне рассказываете что ответ зависит от задачи? Тогда расскажите на каких задачах ORM говно и закат солнца в ручную 1.5-2 раза. Раз в общем случае сказать не можете.

[norguhtar.livejournal.com]

В таком случае ответьте мне чем плох в этом контексте ORM? Он на CRUD операциях как раз таки очень даже удобен.

[norguhtar.livejournal.com]

А я не путаю. Более простой интерфейс нужен не для тех кто софтину пишет, а для тех кто ее будет использовать.

[asvil (from livejournal.com)]

А чё там во втором абзаце предполагается кроссбазовость что ли? Я, несмотря на возраст, хочу высказаться о том, что кроссплатформенности не существует. Работаем с конкретной базой, значит дрючим все её фишки: sequence, returning, window functions, arrays, gis и т.п.
Видел я переход с мускуля на халявный оракл: пауки и черви.

Ближайшие, на мой взгляд, решения это метаклассовость: http://common-lisp.net/project/elephant/, http://www.franz.com/products/allegrocache/. Но они завязаны на common lisp, а common lisp это тот ещё зашквар.

P.S. Excel ок.

[fraks-nsk.livejournal.com]

Как будет выглядеть интерфейс программы - совершенно не зависит от того на чем и как она написана.
На любом инстументе можно написать любую программу.

[norguhtar.livejournal.com]

Это вы к чему? Основная цель программиста в любом случае написать ПО которое автоматизирует тот или иной аспект.

[fraks-nsk.livejournal.com]

Мне как-то не приходится добавлять десятки и сотни полей ежедневно в программу. А 10 полдей в месяц я добавлю без всяких проблем и без всяких ОРМ. Для того что бы внедрить ОРМ надо сделать кучу телодвижений а что поимею в итоге?
Даже начиная новую программу, прочитать/записать данные по полям - занимает достаточно мало времени, работа обезъянья, не затрагивает мозга. А мозг я потрачу на более нужные вещи вместо того что бы тратить его на еще один уровень абстракции и держать в уме как оно на самом деле будет работать.

Для справки - работая на Delphi я давным-давно не использую DB_Aware контролы и компоненты. Вообще. Это тоже такой дополнительный и лишний уровень борьба с которым занимает гораздо больше времени чем получается от него пользы. Особенно в плане предсказуемости поведения. Вместо этого всего у меня один самопальный типа датасетик, похож на ClientDataSet но только он не датасет а просто буфер, поля которого объявляются динамически. У этому датасетику есть компонент который цепляет к себе этот датасет, грид, статус-бар и контекстное меню грида.
Для работы с БД используется FIBQuery, который без буфера, выдает только одну запись.

Если грида не требуется - то вообще кроме переменных ничего не юзаю.
А если поле строковое - то сую прямо в контрол и из него обратно в параметр FIBQuery который Update;

Т.е. написан свой маленький велосипедик который позволяет обходиться минимумом лишних абстракций.

[fraks-nsk.livejournal.com]

Ну, я всего-лишь высказался в стиле айседа, имея ввиду вот это
http://metaclass.livejournal.com/800013.html?thread=17305101#t17305101

[fraks-nsk.livejournal.com]

Автоматизирует аспект задачи или автоматизирует процесс написания автоматизации?
ОРМ - это больше походит на второе.

[norguhtar.livejournal.com]

Мне как-то не приходится добавлять десятки и сотни полей ежедневно в программу. А 10 полдей в месяц я добавлю без всяких проблем и без всяких ОРМ. Для того что бы внедрить ОРМ надо сделать кучу телодвижений а что поимею в итоге?

Это вам не приходится. А когда придется горя вы хлебнете.


Вместо этого всего у меня один самопальный типа датасетик, похож на ClientDataSet но только он не датасет а просто буфер, поля которого объявляются динамически. У этому датасетику есть компонент который цепляет к себе этот датасет, грид, статус-бар и контекстное меню грида.
Для работы с БД используется FIBQuery, который без буфера, выдает только одну запись.

Ничего что это такой маленький свой ORM для решения локальных задач? Фактически если вы дальше Delphi вылезете то увидите что люди к примеру в MVC вполне себе спокойно используют ORM c Model и добавляют любую сложную форму левой ногой. А у вас придется еще и пачку SQL писать. А зачем?

[fraks-nsk.livejournal.com]

Между прочим, без отношения к обсуждаемому вопросу эта фраза - истина.

"мы вместо того чтобы ходить ногами ездим на весьма сложном с технической стороны автомобиле."

[norguhtar.livejournal.com]

ORM это как раз второе. Часто бывает ситуация нужно вчера. И ORM позволяет это делать быстро и часто сводится к добавить поле в Entity ORM

[fraks-nsk.livejournal.com]

Какую пачку SQL?
Один select и один update.

[metaclass.livejournal.com]

В постгресе есть returning? а зачем тогда currval('...')?

[falcrum.livejournal.com]

Да нормально уже давно сиквенсы работают - чё они тебя так возбудили? :)

[metaclass.livejournal.com]

2 и 3 - у меня :)