![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://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 (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
>> Писали работать с данными на сервере, это оно и есть.
Нет, это разные вещи.
>> Еще раз напоминаю, у вас эта проблема есть всегда. Когда вы показали клиенту данные и он полез их
>> редактировать, то он уже изменяет устаревшие данные.
Данные которые можно редактировать - только в специальных формах для редактирования.
Основное количество форм - просмотр, поиск, вывод в разных видах, вычисление агрегатов, отчетов и т.п.
Данные запрашиваются на клиента только что бы показать юзеру. Любые вычисления делаются запросом на сервере и их результат показывается юзеру. Никакие данные с клиента не берутся и на нем не хранятся.
no subject
Нет, это разные вещи.
И в чем же?
Данные которые можно редактировать - только в специальных формах для редактирования.
Это еще что такое?
Данные запрашиваются на клиента только что бы показать юзеру. Любые вычисления делаются запросом на сервере и их результат показывается юзеру. Никакие данные с клиента не берутся и на нем не хранятся.
Да ладно? И как же они попадают на него и как попадают изменения вносимые в базу от пользователя?
no subject
>>>> Это еще что такое?
Я уже писАл об этом.
Схематично - сознательный отказ от редактирования в гриде. Нужно что-то изменить в строке - открываем специальное окно где текущая запись разложена по полям, там и редактируем.
По остальным вопросам - мы говорим на разных языках.
no subject
Схематично - сознательный отказ от редактирования в гриде. Нужно что-то изменить в строке - открываем специальное окно где текущая запись разложена по полям, там и редактируем.
ДА ЛАДНО?! И чем это отличается от редактирования в гриде? Вы меня уверяли что редактируете актуальные данные. А теперь мы редактируем в форме. Ничего что вы редактируете такие же закешированные данные что и в случае с ORM?
no subject
Редактирование в гриде усложняет форму с гридом, без этого легко обойтись.
Редактирование в гриде имеет еще такой минус - нет явного и интуитивно понятного события когда следует записывать изменения в базу. При открытии отдельной формы все понятно - вот кнопочка сохранить а вот - отказаться от сохранения. Панельки с кнопками типа вперед, назад, едит, пост, кансел - я считаю кривым следствием кривой идеологии датасорса.
no subject
Для актуальности - блокировка.
Какая блокировка? В какой момент ставим блокировку? Максимальный уровень изоляции поди не?
no subject
Основной уровень изоляции который я использую - READ COMMITTED. При необходимости получить непротиворечивые данные - REPEATABLE READ.
Блокировка и редактирование естественно происходит с READ COMMITTED.
no subject
Блин, да вы сами почитайте уже про транзакции. Для того что бы заблокировать запись надо внести в нее изменения, можно фиктивные - т.н. "холостой UPDATE" и уровень изоляции транзакции тут не важен, блокировка при любом уровне произойдет, или столкнется с чужой блокировкой поставленной ранее.
Тогда вы просто тупо врете когда говорите, что в случае ORM я сталкиваюсь с проблемой кеширования. Так-как при таком уровне изоляции никакой разницы между актуальностью данных при использовании ORM и ваших методов работы с данными нет.