|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 23 Aug 2002 19:07:53
To : Nik Sestrin
Subject : Re: Отчеты
--------------------------------------------------------------------------------
Hi, Nik Sestrin!
В чреве акулы, пойманной Thu, 22 Aug 2002 16:06:52 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Отчеты':
>> >> _Два_ запроса. Сериализация (которая поставит всех остальных раком)
>> >> здесь не поможет, тут нужен snapshot.
Hик, все просто. Вы говорите о разном.
Hикакой SERIALIZABLE не спасет от ситуации, когда прочли таблицу
дебетов, ПОТОМ В ДРУГОМ ЗАПРОСЕ прочли таблицу кредитов и вот между
запросами - в кредиты что-то добавили.
Тогда будет рассогласование дебетов с кредитами. (Архитектуру системы
и осмысленность запросов я сейчас не обсуждаю). Т.е. тут
рассогласование идет не на уровне выборки, а на уровне логики и
интерпретации данных (дебеты из одной таблицы должны соответствовать
кредитам из другой). Такие вещи констрайнтами не описываются и
поддерживать их БД не обязана. Хотя - если обновление таблиц тоже
будет идти парой и В ТРАHЗАКЦИИ - все будет нормально и согласовано в
любом варианте.
Т.е. обсуждаемая ошибка возможна если:
- по логике работы - обе таблицы должны обновляться одновременно в
транзакции
- но они обновляются по одной, в разных транзакциях
- а читаем мы их в одной транзакции
Винить ли в подобной "кривизне" сервер или допустившего сие
разработчика - решайте сами, по моему сервер тут ни при чем.
А вот то, что якобы один и тот же сложный запрос при повторном
выполнении из за неатомарности наложения блокировок и при SERIALIZABLE
может дать неодинаковые результаты - это позволю себе не поверить,
такие вещи надо доказывать, иначе - это треп и слухи.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
