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

[metaclass]

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

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

Comments

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

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

[vp.livejournal.com]

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

[norguhtar.livejournal.com]

Вы же отлично знаете, что это все отлично крутится в ORM. А так же выявляется довольно просто и чинится так же.

[henu3detb.livejournal.com]

выявляется часто на продакшне, когда данных почему-то стало много.

[fraks-nsk.livejournal.com]

Не. Не так.
На SQL оптимизация выполняется в процессе написания, и гавно видно сразу, кроме кривых планов на возросших данных.
А на ОРМ приложив усилие можно тоже написать гладко, но по дефолту легко получить гавно и не заметить этого.

[norguhtar.livejournal.com]

На SQL оптимизация выполняется в процессе написания, и гавно видно сразу, кроме кривых планов на возросших данных.

Ну рассказывайте, рассказывайте. Что ни разу индекс не забывали?


А на ОРМ приложив усилие можно тоже написать гладко, но по дефолту легко получить гавно и не заметить этого.

На ORM не надо прикладывать усилий чтобы написать гладко. Там точно так же как и в случае SQL мы знаем тут будет много надо сразу сделать оптимизацию. Опять же такая оптимизация туда вносится ровно так же как и в SQL. У меня есть большой проект на ORM JPA и если бы я использовал SQL то усилий я бы затрачивал местами даже больше. Так-как местами пришлось бы выкручиваться а тут как а там как.

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[vp.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

Использование ORM позволяет мне эту прослойку банально по базе сгенерить. Я обычно сначала проектирую СУБД, потом генерю по нему ORM и все. Дальше мне только DAO добавлять нужное. А это я делаю через spring-data http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/repositories.html

В результате создание слоя для работы с СУБД у меня занимает весьма мало времени по сравнению с другими методами. И причем я сразу получаю код который могу отдать другому человеку.

[fraks-nsk.livejournal.com]

У вас наверное проблема в том что кодинг занимает много времени. Вы наверное делаете по приложению в неделю. Может быть да, в вашем случае выпекание пирожков на потоке имеет смысл.
Моей программке начиная от первых версий лет наверное 15 уже, можете прикинуть как часто мне приходится писать новые привязки к полям.

Каждому инструменту - свое место.

[norguhtar.livejournal.com]

У вас наверное проблема в том что кодинг занимает много времени. Вы наверное делаете по приложению в неделю. Может быть да, в вашем случае выпекание пирожков на потоке имеет смысл.

У меня проблема в том что требуется быстрый старт и быстрые изменения. При этом я хочу сконцентрироваться на самом приложении и как оно работает, а не слое работы с СУБД. Если бы вы использовали такой же инструментарий, то ваше ПО развивалось быстрее и вы меньше тратили бы времени на нудное программирование работы приложения с СУБД.

[vp.livejournal.com]

>Я обычно сначала проектирую СУБД, потом генерю по нему ORM и все

Генерите ОРМ по базе? Или как?

[norguhtar.livejournal.com]

Да по базе. Для JPA есть отличный инструментарий в Eclipse. Открываешь соединение говоришь сгенери мне отсюда классов. Далее максимум надо сделать доводку по месту.

[evil-invader.livejournal.com]

Можно наоборот. Набросал энтитей - оно сгенерило таблицы в базе. Но это в простом случае. А так конечно по базе оно очень чётко генерит нужные классы.