![[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
Это я про то что для вычислений не надо тащить данные на клиента и обрабатывать клиентом. Все что можно сделать на сервере - надо делать там.
Эммм.... редактирование данных на сервере? Вы в курсе для чего придумывались РСУБД? Вы в курсе, что хранимки так же оборачиваются в транзакцию? Еще раз подчеркну мы всегда работаем с устаревшими данными, это суть РСУБД.
То что вы называете максимальным уровнем изоляции - является блокировкой от изменений.
Это называется максимальным уровнем изоляции у транзакции. Учите матчасть.
ОРМ на устаревание влияет тем что хранит данные какое-то время на клиенте.
У вас это происходит всегда. Как только вы отобразили пользователю в форме данные с сервера, они устарели. ORM на это никак не влияет.
Если этой возможностью ОРМ не пользоваться то оно вырождается в странную прокладку между результатом запроса и контролом.
У вас весьма странные представления о ORM. Инвалидацию кеша никто не отменял. К примеру если я запросил обновление данных, то объект не будет создан по новой, а сначала произойдет проверка валидности данных. Если валидны мне вернут данные из кеша ORM, если нет то обновится уже существующий объект и будет отдан он.
no subject
В курсе. В Firebird вне транзакции можно только генератор дернуть.
Я не писал "редактирование на сервере", читайте внимательнее.
"Сериализуемость (serializable) — максимальный уровень изоляции, гарантирует неизменяемость данных другими процессами до завершения транзакции. "
Это означает что то что мы поменяли не сможет поменять другой. Невозможность поменять это и есть блокировка. Конфликт обновлений.
Кэш на клиенте и соответственно нужна в его валидации - это и есть один из минусов идеологии ОРМ.
no subject
Я не писал "редактирование на сервере", читайте внимательнее.
Писали работать с данными на сервере, это оно и есть.
Кэш на клиенте и соответственно нужна в его валидации - это и есть один из минусов идеологии ОРМ.
Еще раз напоминаю, у вас эта проблема есть всегда. Когда вы показали клиенту данные и он полез их редактировать, то он уже изменяет устаревшие данные. Данные с сервера у вас кешируются всегда. То что вы внезапно видите этот кеш на уровне 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 и ваших методов работы с данными нет.
no subject
http://ibase.ru/devinfo/plocks.htm
Блокировка НЕ транзакцией - например если сервер не поддерживает транзакции. Или если надо блокировать на длительное время что транзакцией делать крайне нежелательно - тогда флагами, таблицами со списком блокировок, отдельным приложением которое ведет списки блокированных объектов... мало ли чего можно придумать.
Вот атомарность транзакции или ее свойство Repeatable Read никаким другим механизмом не заменишь. А блокировку в принципе можно.
no subject
no subject
no subject
no subject
no subject
А то специальные формы, данные изменяются на сервере.
no subject
no subject