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

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

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

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

Threaded | Top-Level Comments Only

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

А когда епонцы делают яп для епонцев — что получается?

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

Мой опыт с автоматизаторами автоматизации говорит о том что разборки с тем что же оно там наавтоматизировало и как побороть вот такое его поведение что бы сделать так как я хочу занимает гораздо больше времени чем тупо набить все руками. Это примерно то же самое как в спешке ехать пытаясь сократить дорогу - всегда выходит дольше чем ехать как обычно :)

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

Еще есть такая штука как совместимость.
Как работает мой велосипедик я знаю, и он по минимуму завязан на что-то стороннее.
А вот бывает пытаешься заюзать новую версию чего-то, оно требует поменять версии еще кучи всего, вся эта куча в неопределенных местах может поменять поведение и в итоге программа перестает нормально работать. Чем больше разнообразных библиотек и инструментов - тем хуже ситуация.

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

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

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

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

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

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

Документацию читать не пробовали? Вы или работали с каким-то очень кривым ORM или не читали документацию. Если бы я лабал то количество кода которое я банально генерирую по РСУБД, то я бы конкретно утомился.

ОРМ-хейтеры, типа вас, такие же фанбои, как и SQL-хейтеры. "Всему свое время, и время всякой вещи под небом".

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

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

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

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

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

Знаете это больше похоже на боязнь нового. Я понимаю что далеко не все могут адекватно оценить последствия применения той или иной технологии. Но использование готовых сторонних инструментов позволяет экономить кучу времени. Единственное но надо правильно оценить инструмент. Все же группа адекватных разработчиков которые делают фреймворк лучше сделают его чем я в одну харю. Потому что я банально охвачу меньше аспектов чем они.

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

В mysql их не наблюдается, в mssql они появились только в 2012 версии, возвращение последнего значения - кто во что горазд.

Да, это боязнь нового.
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.

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

Edited 2013-04-03 06:42 (UTC)

в постгрессе returning, начиная с 8.2 по моему.
В mysql поле в reply пакете (last_insert_id рядом с affected_rows)

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

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;

Реалии таковы что документация либо отсутствует либо там описаны элементарные вещи а все остальное - копай на примерах и на собственных шишках + лазай по чужому коду и смотри что они там понаписали. Нафиг такое щастье. Самому бывает быстрее написать чем в чужом разобраться.

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

Ну так ты и есть технодрочер :)

Да, это боязнь нового.
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.

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

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

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

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

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

Threaded | Top-Level Comments Only

Page 3 of 15

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

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject