![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclasshttp://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-04-04 02:46 am (UTC)>>>> Это еще что такое?
Я уже писАл об этом.
Схематично - сознательный отказ от редактирования в гриде. Нужно что-то изменить в строке - открываем специальное окно где текущая запись разложена по полям, там и редактируем.
По остальным вопросам - мы говорим на разных языках.
no subject
Date: 2013-04-04 03:08 am (UTC)Схематично - сознательный отказ от редактирования в гриде. Нужно что-то изменить в строке - открываем специальное окно где текущая запись разложена по полям, там и редактируем.
ДА ЛАДНО?! И чем это отличается от редактирования в гриде? Вы меня уверяли что редактируете актуальные данные. А теперь мы редактируем в форме. Ничего что вы редактируете такие же закешированные данные что и в случае с ORM?
no subject
Date: 2013-04-04 03:21 am (UTC)Редактирование в гриде усложняет форму с гридом, без этого легко обойтись.
Редактирование в гриде имеет еще такой минус - нет явного и интуитивно понятного события когда следует записывать изменения в базу. При открытии отдельной формы все понятно - вот кнопочка сохранить а вот - отказаться от сохранения. Панельки с кнопками типа вперед, назад, едит, пост, кансел - я считаю кривым следствием кривой идеологии датасорса.
no subject
Date: 2013-04-04 03:30 am (UTC)Для актуальности - блокировка.
Какая блокировка? В какой момент ставим блокировку? Максимальный уровень изоляции поди не?
no subject
Date: 2013-04-04 04:13 am (UTC)Основной уровень изоляции который я использую - READ COMMITTED. При необходимости получить непротиворечивые данные - REPEATABLE READ.
Блокировка и редактирование естественно происходит с READ COMMITTED.
no subject
Date: 2013-04-04 04:36 am (UTC)Блин, да вы сами почитайте уже про транзакции. Для того что бы заблокировать запись надо внести в нее изменения, можно фиктивные - т.н. "холостой UPDATE" и уровень изоляции транзакции тут не важен, блокировка при любом уровне произойдет, или столкнется с чужой блокировкой поставленной ранее.
Тогда вы просто тупо врете когда говорите, что в случае ORM я сталкиваюсь с проблемой кеширования. Так-как при таком уровне изоляции никакой разницы между актуальностью данных при использовании ORM и ваших методов работы с данными нет.