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

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

Жабу и автоматизацию в одной строке упоминать не принято :)

[fraks-nsk.livejournal.com]

ORM - это надо в программе завести классы аналогичные тем что имеются в базе. Т.е. дублирование.
Дальнейшая работа с этими классами подразумевает что они имеют заполненные поля. А заполнятся они могут как все сразу (это неэффективно) так и по одному полю (тоже неэффективно, но уже по другому). В итоге для работы с объектами в ОРМ либо тянется куча по большей части ненужных данных либо генерится туча запросов на каждый чих.

Далее, если мы работаем с выборками по сложным запросам - тут мы или лепим в ОРМ левые классы не имеющие реального отражения в БД либо тянем коллекции классов с опять же нахрена не нужными полями.

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

[metaclass.livejournal.com]

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

[fraks-nsk.livejournal.com]

Я смотрел SQLAlchemy и мнение об ОРМ сформировалось на этой основе.
Потом для Delphi сделали аналогичную фигню, был на форуме фанат этой штуки, типа программу накидать за пару дней можно. Но потом он столкнулся с минусами - с поддержкой, модифицированием формы объектов в базе и необходимости синхронизации изменений в ОРМ - и энтузазизм его угас, вроде даже до нуля, ибо тему ту больше никто не поднимал да и упоминания того продукта я не слышал больше. Хотя он от Борланд/Эмбаркалеро был, а не левый.

[fraks-nsk.livejournal.com]

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

[metaclass.livejournal.com]

Народ генерит базу из классов или маппингов. В первом случае класс засран по крышу аннотациями на полях, во втором - нам надо знать убогий синтаксис маппингов (в дополнение к sql и собственно ЯП)

[fraks-nsk.livejournal.com]

>> Вы надеюсь понимаете, что в итоге пополните ряды разработчиков на COBOL?

Они до сих пор восcтребованы, как ни странно :)

>> Вы не поверите, но есть фреймворки общего назначения.

Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.

[vp.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[vp.livejournal.com]

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

[norguhtar.livejournal.com]

Ой да ладно.

[theiced.livejournal.com]

есть ещё рубёвый вариант ;]

[norguhtar.livejournal.com]

ORM - это надо в программе завести классы аналогичные тем что имеются в базе. Т.е. дублирование.
Дальнейшая работа с этими классами подразумевает что они имеют заполненные поля. А заполнятся они могут как все сразу (это неэффективно) так и по одному полю (тоже неэффективно, но уже по другому). В итоге для работы с объектами в ОРМ либо тянется куча по большей части ненужных данных либо генерится туча запросов на каждый чих.

А в формы вы не заводите и данные туда не отображаете да? Все святым духом делается? И в MVC частенько упоминаемые вами классы используются как формы. Может вы мат. часть подучите а?


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

Учите мат. часть. Вы мягко говоря не правы. ORM это маппинг объектов а не вытаскивание данных из базы. Вы этот маппинг делаете каждый раз когда данные селекта показываете в форме.

[theiced.livejournal.com]

на делфи там нихуя нет а кроме делфи эта амёба нихуя не знает

[vp.livejournal.com]

У тебя логика работы смешана с кодом ФОРМЫ на ПАСКАЛЕ!!

Щас позову Айсда, не уходи..

:)

[norguhtar.livejournal.com]

Прям

Я лучше код пишу чем все остальные!


Надо понимать, что если я в одну харю такое решение буду делать, то убью существенно больше времени и результат будет хуже. Тупо за счет того что те люди занимаются этим больше времени чем я.

Ну а то что там могут быть черви и пауки, так это везде есть. И на стадии оценки стоит ли использовать и требуется оценить их количество.

[thedeemon.livejournal.com]

Ruby

[norguhtar.livejournal.com]

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

С указанными минусами вы и со своим велосипедом столкнетесь. И да SQLAlchemy не самый худший вариант, но конечно JPA и ORM который есть в yii все же лучше. Фишка в том что ORM ни в коем случае не надо тащить самому, иначе эта овчинка не стоит выделки. Разрабатывать и сопровождать ORM должны отдельные люди.

[norguhtar.livejournal.com]

Они до сих пор восcтребованы, как ни странно :)

Их количество существенно сократилось.


Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.

Конечно конечно. К примеру Delphi

[fraks-nsk.livejournal.com]

Если данные в объекте ОРМ не закачиваются при создании экземпляра коллекции то они вытягиваются по факту обращения к объекту или к полю объекта. Итого либо мы все тащим заранее или вырождаемся в запрос каждого поля по каждому обращению.

[norguhtar.livejournal.com]

у делфи во время ее популярности была ровно та же проблема что у php это пропаганда говнокода. Тяп-ляп готово. А что надо еще о архитектуре думать вспоминали когда такого говна было дохуя.

[thedeemon.livejournal.com]

пора писать 1!

[fraks-nsk.livejournal.com]

Зови, мне не жалко.

Если логика работы используется более чем в одном месте - то я выношу это в отдельное место. Если эта форма - единственное место где у меня работа с этим объектом - нахрена мне это разделять? Что бы каноны соблюсти?

[norguhtar.livejournal.com]

Как вы мало знаете о ORM. В ORM есть возможность сказать это взять через join и сразу.

[fraks-nsk.livejournal.com]

>> С указанными минусами вы и со своим велосипедом столкнетесь.

Не столкнусь. У меня не ОРМ, я не работаю с объектами в программе. Все объекты только в базе, на клиенте только нужные в конкретном объеме выборки которые не претендуют на полноту данных об объекте но показывают те поля которые именно здесь нужны.