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