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

[metaclass]

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

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

Comments

[fraks-nsk.livejournal.com]

Это ОРМ - тотальное гавно ибо
- собственно данные хранить не умеет
- все равно для адекватной эффективности приходится смотреть на работу с СУБД.

Итого - ОРМ всего-лишь ненужная прокладка.

Утрированно.

[vp.livejournal.com]

>Итого - ОРМ всего-лишь ненужная прокладка.

Я как бы не согласен совсем. Эффективность адекватна, если уметь этих кошек готовить. Например, Hibernate генерирует при правильном конфиге именно те запросы, которые бы написал сам.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

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

[vp.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[vp.livejournal.com]

Давайте определимся с целями и задачами, а то так далеко зайдем.
Цель - не "сгенерить по имеющимся классам какую-то базу и какой-то ДАО". Получится херня.
Должна нормально вдумчиво проектироваться база, под нее писаться на ОРМе прослойка. Цель прослойки - упрощение работы с базой и простота будушего рефакторинга. Но мозг это не отменяет, и то, что он генерирует, нужно смотреть глазами.

[fraks-nsk.livejournal.com]

Со всем согласен, кроме того что прослойка должна писаться на ОРМ.
И вообще, толщина прослойки начинается от нуля.

[fraks-nsk.livejournal.com]

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

[veremeenko-alex.livejournal.com]

Хранимки еще большее зло. Логика растекается по программе, базе данных, UDF.
Рефакторинг становится анальной карой.

[fraks-nsk.livejournal.com]

Не надо раскидывать логику и ничего не будет растекаться.

[vp.livejournal.com]

Безусловно, это не золотой костыль. Потому мозг все равно нужно включать :)

[metaclass.livejournal.com]

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

[nivanych.livejournal.com]

Поделитесь, как ви на поцгресе запросы обычно хинтами перепиливаете?

[metaclass.livejournal.com]

У меня нет постгреса в таких масштабах пока.

[darkdrip.livejournal.com]

всё блять. буду писать сайтики на mod_plsql. нахуй эти прокладки нужны?

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

ОРМ - это закат солнца вручную 1,5-2 раза.

[norguhtar.livejournal.com]

Да ладно? Может поделитесь как надо тогда делать? Мне вот правда интересно.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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