|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Liliya Huff 2:5020/400 21 Aug 2002 22:30:04
To : Nik Sestrin
Subject : Re: Отчеты
--------------------------------------------------------------------------------
Добрый день!
> в mssql можно использовать сериализуемое выполнение транзакций ... а
вообще
> да, налицо явное непонимание, что такое транзакция
ms sql работает с блокировками, как и у любого блокировщика, прежде, чем
наложить блокировку, сервер определяет целевое множество блокирования, по
сути это набор идентификаторов записей (никуда не денешься, блокирование
предикатов не реализовано ни у кого), а этот процесс занимает время, и
вообще говоря не является не прерываемым, так как он фактически составная
часть операции execute. То есть даже при использовании сериализуемых
транзакий в данном случае снимок базы мы не получаем по одной очень простой
причине: фантомы и прочее предотвращаются на том множестве записей, которая
транзакция уже запрашивала (по сути при serializable туда грубо попадают
таблицы, к которым было обращение в select запросах). Если при выполнении
запроса 1 и запроса 2 используются одни и те же таблицы, то тогда все хорошо
более-менее, за исключением того, что параллельные транзакции будут ждать
снятия блокировки, но тут уж у них судьба такая. Если же при выполнении
запроса 2 используются какие-то таблицы X, не запрашиваемые запросом 1, то
тогда вообще говоря ситуация работы со снимком (при выполнении обоих
запросов даные те же) не гарантирована, так как никто не предотвращал
модификации по этим самым X. Поэтому вообще говоря уровень serializable и
работа со снимком базы (snapshot) - это вообще говоря не одно и то же.
> автору исходного вопроса: нет причины, не позволяющей расчитать
> остатки/движение/etc. одним выражением даже при самой бредовой схеме.
кроме
> разве что убогости субд, не имеющей юнионов и вложенных запросов
По каким причинам автор вопроса не может сделать все одним запросом - это
уже отдельная проблема, и она автором вопроса не поднималась, поэтому ... ну
может быть есть на то причиы (да какие угодно, от ограничений диалекта sql
до скоростных характеристик... ну если оптимизатору по каким-то причинам 2
запроса съесть быстрее чем один большой, ну не все оптимизаторы совершенны).
Что же касается замечания о том, что если все сделать одним запросом, то
сразу всем станет существенно легче, то это так же зависит от СУБД с какой
работает автор вопроса. То, что выполнение запросов select
распараллеливается не является уже чем-то необычным, и давно. Вероятность
наступить на фантом даже при выполнении одного запроса меньше, но не 0.
Прежде всего надо смотреть, как и когда накладывает блокировки (или что у
него там есть) сервер. Если блокируется все множество записей, которые может
запросить запрос, а потом идет выполнение выборок, тогда все может
прокатить, но не факт что оно так работает. Причина того, что не факт
простая: или придется блокировать грубо большие блоки данных (первичная
эскалация блокировки), тогда параллельность выполнения запросов резко
падает, или выделять точное множество блокирования (набор id записей), а это
фактически отработка в процессе execute - никуда не денешься, что требует
времени, и если этот процесс наложения блокировки не прерываем, то пока
даный запрос не закончит со своим множеством, то все висят и ждут у входа,
что просадит параллельность выполнения запросов еще сильнее.
Именно запросы union в данном случае идеальный кандидат на
распаралеливание - это фактически 2 запроса, которые сливаются в один
результат в самом конце, значит это очень хороший кандидат на
распараллеливание выполнения такого запроса, со всем вытекающими
последствиями. Когда выполнение запроса было непрерываемым (как это и
предполагается в теории), то вопросов нет, все будет хорошо, но когда запрос
может распараллеливаться сервером, то ... и теория несколько должна
измениться. Поэтому и аномалии чтение-запись внутри запроса вообще говоря
можно получить (в частности фантомы).
Остается вопрос, обладает и такой особенностью сервер, о котором идет речь
(автор его забыл назвать), то есть умеет ли распараллеливать запросы, и если
да, то как. От этого фактора в том числе будет зависить решение вопроса.
Если уж очень хочется сделать snapshot базы, то выкрутиться можно, даже если
у сервера такого уровня изолированности нет. придется вводить временные
метки, то есть хранить данные со временем. Это как обычно имеет свои минусы:
- сервер должен реализовывать аналог datetime или сам этот тип (зависит от
вкуса программиста, что больше нравится использовать)
- в запросы будет по определению входить дополнительное условие на <=
константа, что влечет дополнительный индекс (его наличие замедлит dml
операции) и сам поиск по datetime далеко не быстрый по сравнению с теми же
int.
Поэтому выбор решения в этот месте тоже может быть не однозначе, вдруг по
скоростным или каким-то еще характеристикам такое решение не подойдет.
--
Regards, Lilya Huff
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
