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

[metaclass]

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

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

Comments

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[fraks-nsk.livejournal.com]

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

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

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

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

[norguhtar.livejournal.com]

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

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


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

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

Давайте последовательно посмотрим на вопрос. У вас select и update пишется на каждую форму которая представляет собой сущность так ведь? И таких форм у вас может быть не одна так?

[fraks-nsk.livejournal.com]

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

[metaclass.livejournal.com]

Добавляют любую сложную форму левой ногой?
Может оно еще и Windows Forms контролы генерить умеет, и модель содержит не то, что пауки микрософту приказали, а нужную информацию о типах и полях?

[theiced.livejournal.com]

а, ещё и делфи для полноты диагноза. и самописные велосипёды с сикль запросами ручными. специалист блеать конченный.

[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 то усилий я бы затрачивал местами даже больше. Так-как местами пришлось бы выкручиваться а тут как а там как.

[fraks-nsk.livejournal.com]

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

Честно говоря не пойму про что вы говорите, где и как можно забыть индекс.
Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.

Где тут можно забыть индекс?

[norguhtar.livejournal.com]

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

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


Запрос пишется и отлаживается в IBExpert, там же контролирую статистику чтений индексных, неиндексных, смотрю план. Если что не нравится - корректирую/переписываю запрос. Можно играться хинтами но я этого не умею и в принципе не хочу использовать т.к. это дело иногда меняется, в новых версиях сервера. Зарулить запрос на использование нужных мне индексов можно используя outer join и хаки типа "+0".
После отладки текст запроса копируется в компонент в Delphi.

Учтивая характер того как вы разрабатываете, не удивительно. Но такая скорость разработки для любого другого софта просто не приемлема. Как правило фича нужна не через месяц как разработчик насладится игранием в explain и его адаптацией к конкретной ситуации, а завтра. В этом случае есть время выработать внятные подходы со слабой связностью. Чтобы в случае чего было просто это переделать. Но это же хотя и позволяет делать ошибки, но позволяет так же исправлять их просто и быстро.

[metaclass.livejournal.com]

Какой месяц на explain, каких данных мало?
Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.

Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".

[fraks-nsk.livejournal.com]

Вы как-то странно делаете вывод о моей скорости из описания процесса.

Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%

ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.

Что такое "разработчик насладится игранием в explain и его адаптацией к конкретной ситуации" - я не понял.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.

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

[anonim-legion.livejournal.com]

Как правило, люди не умеют планировать, поэтому требуют "фичи" "ко вчера". Больше нипочему.

[theiced.livejournal.com]

>Запрос пишется и отлаживается в IBExpert,

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

[fraks-nsk.livejournal.com]

Это вы про метакласса? :P