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

[metaclass]

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

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

Comments

[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]

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

Если образуются запросы которые могут быть использованы из нескольких форм или запросу не нужна форма - то они выносятся в общий датамодуль или в отдельный специализированный юнит.

У меня нет нигде редактирование в гриде. Редактирование только в отдельной форме которая раскрывает эту запись по полям. И такая форма в которой реализуется редактирование - одна на каждый тип объекта.
А вот запрашивать данные используя много типов объектов - это как правило на каждой форме свой запрос. Но для таких форм не надо ничего объявлять, просто пишется запрос который автоматом создаст потребные поля в датасетике. Вызываем метод в датасетике подсовывая ему объект Query - оно и выполняется и отображается.

[norguhtar.livejournal.com]

Вот все что вы описываете и есть ORM. Разница между стандартным ORM и вашим в том что в случае подключении стороннего разработчика или передачи кода вашего проекта другому разработчику ему придется изучать ваш код для понимания логики где тут что лежит. В случае стандартного ORM ему будет достаточно почитать спецификацию. Плюс все нормальные ORM позволяют модифицировать то как они лезут в базу. И да в 90% случаев они лезут в базу как вы бы сами полезли, а кода писать приходится существенно меньше.

[fraks-nsk.livejournal.com]

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

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

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

[fraks-nsk.livejournal.com]

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

[fraks-nsk.livejournal.com]

Вот процедура обновления списка региональных агентов.

procedure TFrmAgent.F5;
begin
CDV.RowSavePosition; {сохраним текущую позицию}
{}
CDS.ExecSelect(QSel);
CDV.Sync;
{}
CDV.RowRestorePositionID; {восстановим позицию курсора если она была}
end;

А вот процедура чтения данных по одному региональному агенту, для редактирования.
Справочник элементарный, типа id, name, поэтому даже форму ему для редактирования делать не стал.

procedure TFrmAgent.F2; {редактирование элемента справочника}
var
id: integer;
sname: string;
iRow: cardinal; {текущая выбранная строка в дереве}
begin
if not CDV.RowSelected(iRow) then Exit; {если ни одна строка не выбрана}
{на CDS.Count > 0 можно уже не анализировать, иначе бы ничего не было выбрано}
id := CDS.ReadIntegerFN(iRow, 'ID');
QS.ParamByName('id').AsInteger := id;
QS.ExecQuery;
if QS.EOF then Exit;
sname := QS.FieldByName('name').AsString;
TransRC.Commit;
{}
if not InputQuery(Caption, 'Редактирование регионального агента', sname) then Exit;
{}
QU.ParamByName('id' ).AsInteger := id;
QU.ParamByName('name').AsString := sname;
Open_Query(QU);
TransRC.Commit;
F5; {позиционирование на старый ID - внутри}
end;

[vp.livejournal.com]

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

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

:)

[fraks-nsk.livejournal.com]

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

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

[theiced.livejournal.com]

а чего меня звать, я тут. но я даже не буду ЭТО комментировать, поделка на уровне студента рти/сотрудника нии гит с 40летним стажем. неподдерживаемо, немэйнтабельно, нерасширяемо, нетестируемо и не работает. такой код имеет исключительно один "плюс" - мудака его написавшего так просто с работы не попрёшь.

[vp.livejournal.com]

У меня еще претензия к названию методов: F2, F5
Они никак не отражают сути того, что делают эти методы.
далее, в методе F2 у вас несколько раз используются одни и те же строковые константы: 'id', 'name'. Положено такие вещи выносить хотя бы константы на уровне класса.
Комментарии в конце строки, заключенные в {} - неоправданы. 100 лет как для этой цели используется синтаксис комментариев с //
Конструкция if .. then Exit в одну строку. Правильный формат - Exit переносится на следующую строку с отступом как на следующий блок кода.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

Вы сами поняли что сказали? На чем будет падение эффективности? На выборке или передаче данных по сети?


Я же храню и имею ввиду объекты только в базе, на клиента вытаскиваю только то что нужно в конкретном месте. Если нужно разные поля объектов завязать друг с другом - использую логику на сервере.

Вы не поверите, но ОRM такое позволяет без всяких проблем. И да если уж внезапно у меня есть толстый объект я могу указать ORM как дернуть в этом случае. И объем кода с ORM и без ORM в этом случае будет сравним. Вы бы сначала посмотрели что такое ORM более детально и как он работает, а уже потом что-то про него говорили.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[norguhtar.livejournal.com]

Я вообще про java. Там к примеру есть такая вот чудесная вещь как JSR-303 http://jcp.org/en/jsr/detail?id=303
И много других полезных автоматизаций.

[metaclass.livejournal.com]

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

[norguhtar.livejournal.com]

Ой да ладно.

[nivanych.livejournal.com]

Правильно будет как-то так —
ЖАБАЙ
АВТОМАТИЗИРУЙ

[anonim-legion.livejournal.com]

Я вот все жду, когда вы до явовского Swing'а доберетесь. Было бы очень интересно почитать именно ваше мнение.

а ведь есть еще и Vaadin...

[theiced.livejournal.com]

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