Несостоятельное чтение в СУБД на SQL

← →
Дмитрий Тимохов (2010-10-22 22:45) [0]

Добрый день.

Интересно знать мнение специалистов по следующему вопросу.

АБСТРАКТ
Думаю, большинство из посетителей форума связаны с SQL-СУБД.
На подобных БД можно решать много задач с различными требованиями.

Мои бухгалтерско-аналитично-учетные задачи подразумевают использование объектов предметной области, которые представляются нетривиальными структурами БД (т.е. не запись в таблице, а записи во многих таблицах).

ПРИМЕР.
Возьмем, например, заказ на товар. Состав документа - реквизиты покупателя и рекодсет товарных позиций. Данные для документа собираются несколькими запросами. Между запросами может (теоретически!!!) вклиниться другой пользователь и изменить данные - в результате прочтенный документ окажется несостоятельным - тело от коровы, а голова от лошади.

ТЕПЕРЬ ВОПРОС.
Кто как решает проблемы корректного чтения в аналогичной ситуации?
Какие средства конкретной СУБД используете?
Может "забиваете" на проблему?

← →
Sergey Masloff (2010-10-22 22:50) [1]

Да не проблема - это же классический случай оптимистические и пессимистические блокировки. Хочешь "жостко" - сразу делаешь при выборке select... for update враг который захочет схватить - сразу получает отлуп. Или по-мягкому - кто первый закоммитил тот и прав а второй получит отлуп при попытке коммита.

Хотя наверное ты о чем-то другом - это ты наверняка знаешь

← →
Sergey Masloff (2010-10-22 22:51) [2]

Дим наверное это старость - пятница почти 11 вечера а мы о работе ;-)))

← →
Игорь Шевченко © (2010-10-22 22:52) [3]

транзакции - рулез фарева

← →
MsGuns © (2010-10-22 23:59) [4]

ИМХО, товарищ путает заказы со счетами-фактурами

← →
Дмитрий Тимохов (2010-10-23 00:03) [5]

Сергей, я еще подумаю, что ответить.

Игорь, а какие транзакции? Какой уровень изоляции ты выбираешь при чтении?

ЗЫ я знаю, что Игорь - это Oracle, я знаю, что Oracle - это версионник, я знаю, что про версионники слагают легенды. Вот я и хочу понять - неужели версионники знают заказы на товар и умеют создавать атомарность чтения для них?.

ЗЗЫ. В моем случае я предусмотрел внутренние средства контроля целостности. Своего рода (идейно) - это та же оптимистическая блокировка: если неконсистентно чтение, то отлуп - читай заново (стараюсь скрыть это от пользователя). Но, возможно, есть лучшие практики?

← →
Дмитрий Тимохов (2010-10-23 00:06) [6]

> MsGuns © (22.10.10 23:59) [4]

Предлагаю без конкретики предметной области. Предлагаю абстрагироваться от нее.

Меня интересуют технические решения для обеспечения согласованного чтения сложных структур в многопользовательских системах. Возможно, мой вопрос - своего рода холли вор версионники-блокировочники. Я хочу понять, кто что думает по теме.

Вопрос носит общий характер - консистентное чтение документа в SQL-СУБД.

← →
MsGuns © (2010-10-23 00:07) [7]

Если речь идет о счетах-фактурах, составляемых в "горячем" режиме (т.е. несколько операторов выписывают одновременно счета для нескольких покупателей/заказчиков), то не обойтись без резервирования, которое и в полном объеме позволяет решить проблему "дефицита" позиции товара.

← →
MsGuns © (2010-10-23 00:12) [8]

О какой конкретике речь ? Боже упаси, все исключительно абстрактно.
Однако как построить механизм "разрулирования" конфликтов, не вникнув в физический смысл источника их возникновения.
Это не просто слова, а реально необходимое условие для решения проблемы.
Что касается "ителлекта" Оракла, якобы "знающего" про схему работы с "заказами" - все много проще. Оракл вообще не знает ни про какие "заказы", его фича - это поддержка целостности БД, обеспечиваемая именно транзакционностью. "Версионность" - это лишь технология, но никак не особенность и тебе вообще не стОит на это заморачиваться. По крайней мере пока.

← →
MsGuns © (2010-10-23 00:22) [9]

>Дмитрий Тимохов (23.10.10 00:06) [6]
>Меня интересуют технические решения для обеспечения согласованного >чтения сложных структур в многопользовательских системах.

У.. круто загнул :) Сам-то понял ?
Не стоит "заворачивать" простые мысли в сложные обрертки, иначе можно получить аццкую смесь супертерминологии с бесмыслицей, как это сделано в ветке про оптимальную структуру (http://delphimaster.net/view/15-1287493341/)
Можно легко потерять лез за тремя осинами

>Возможно, мой вопрос - своего рода холли вор версионники->блокировочники.

Можно вопрос - какое отношение имеет технология SQL-сервера к решению задачи складского (или любого другого) дефицита ?

>Вопрос носит общий характер - консистентное чтение документа в SQL-СУБД.

Опять "умное" слово :)
1) Что означает "консистентное" чтение документа ?
2) Что означает "документ" с т.зр. SQL ?
3) Что такое SQL-СУБД ?

← →
Дмитрий Тимохов (2010-10-23 00:23) [10]

> MsGuns © (23.10.10 00:12) [8]

Конкретизирую вопрос. Вернее, деконкритизирую - вопрос носит общий характер, можно сказать, общепознавательный.

Вот представь себе, есть некий инструментарий для создания компьютерных систем, например система "два-эс", представь, что такая есть. Эта система имеет обобщенный язык программирования. Теоретически на 2С можно делать любую систему учета чего-либо.

И вот разработчик озадачивается аналогичным с топиком вопросом - а как сделать, чтобы любой документ в 2С при чтении был консистентен? Может блокировать полностью систему на момент чтения? Может

ЗЫ 2С приведена в качестве примера для того, чтобы описать ситуацию, когда необходимо создать обобщенную систему реализации консистенонго чтения.

← →
Дмитрий Тимохов (2010-10-23 00:26) [11]

> MsGuns © (23.10.10 00:22) [9]

Товарищ, ты согласись, что у каждого свой опыт. У меня свой, у тебя свой.
Ты задаешь мне вопросы на мои вопросы, которые, скажем прямо, ставят меня на уровень, ниже того, на который я ставлю себя сам.

Я прошу тебя избавить текущий топик от твоего присутствия, если ты ставишь перед собой цели, которые мне не нужны.

← →
MsGuns © (2010-10-23 00:32) [12]

Если под "консисентностью" имеется в виду целостность "документа", т.е. гарантированно неизмененный контент документа на момент НАЧАЛА чтения его приложением А при возможных попытках изменения этого же документа приложениями В и С, то эта самая гарантия и обеспечивается пресловутым уровнем изоляции транзакций. А каким образом ск-сервер обеспечивает эту "гарантию", копией документа (версионник) или с помощью журнала (блокировочник) в данном случае проектировщика абсолютно не должно колыхать. Главное, он должен быть уверен, что скл-сервер ГАРАНТИРУЕТ ему эту возможность

← →
Дмитрий Тимохов (2010-10-23 00:34) [13]

> MsGuns © (23.10.10 00:32) [12]

и что serializable ставить?

← →
MsGuns © (2010-10-23 00:34) [14]

У тебя нет опыта или он совсем мал, что видно из твоих вопросов
Но.. Как прикажешь, я более тебя не беспокою.
:))

← →
MsGuns © (2010-10-23 00:36) [15]

>Дмитрий Тимохов (23.10.10 00:34) [13]
>и что serializable ставить?

Да, "опыт" чувствуется" :)
Для начала надо почитать книжки и понять назначение и принцип работы транзакций.

← →
vuk © (2010-10-23 00:39) [16]

А вот нефиг документы менять когда попало, да еще из разных мест! :)

← →
Игорь Шевченко © (2010-10-23 00:39) [17]

Дмитрий Тимохов (23.10.10 00:03) [5]

Я тебя так понимаю:
есть пара (десяток) таблиц, связанные отношением один-ко-многим. Ты выбираешь запись из первой таблицы и совокупность записей из второй (третьей...десятой) таблиц, связанных по ключам с первой. При этом ты подразумеваешь, что в произвольный момент времени другой пользователь может наделать кучу изменений во второй...десятой таблицах и ты получишь неконсистентные, по твоему мнению, данные.

В этом случае надо блокировать первую запись и это гарантирует, что данные, полученные тобой из первого запроса и последующих, не будут изменены между запросами, при условии, что остальные при изменениях будут использовать ту же блокировку.

Либо поставить уровень изоляции транзаккций SERIALIZABLE, при этом СУБД будет обеспечивать режим, как если ты был единственным пользователем (на время выполнения твоей транзакции)

> я знаю, что Oracle - это версионник, я знаю, что про версионники
> слагают легенды

в Oracle операции записи не блокируют операции чтения и наоборот.

← →
Дмитрий Тимохов (2010-10-23 00:49) [18]

> Игорь Шевченко © (23.10.10 00:39) [17]

Собственно, вопрос вот почему возник.
Проект большой, поэтому постоянные доработки, рефакторинг и т.д.

Вот сегодня набрел на свой коментарий 10-летней давности о том, что надо вопрос консистентного чтения решить на уровне транзакций. Повторюсь, что при чтении документ обеспечивает свою целостность. Но это было привнесено искусственно - т.е. было придумано и вроде как работает (как минимум логи не говорят о том, что документ закачался "кривой").

Насчет serializable у меня тоже коммент есть.
Т.к. дело было 10 лет назад, тот у меня не было еще уверенности, что в блокировочниках подобный уровень изоляции есть хорошо.

ИНТЕРЕСУЕТ. Использует ли кто-то serializable в MSSQL-Server для решения задачи целостного чтения?

> MsGuns © (23.10.10 00:36) [15]
>
> >Дмитрий Тимохов (23.10.10 00:34) [13]
> >и что serializable ставить?
>
> Да, "опыт" чувствуется" :)

Ты же не хотел отвечать больше.
Ну не сложилось у нас общение сегодня... Я, пожалуй, пообщаюсь с другими. Хорошо?

← →
Игорь Шевченко © (2010-10-23 00:59) [19]

Дмитрий Тимохов (23.10.10 00:49) [18]

У каждой СУБД свои тонкости, с MS-SQL не работал, ничего сказать не могу.

← →
Дмитрий Тимохов (2010-10-23 01:03) [20]

> Игорь Шевченко © (23.10.10 00:59) [19]
>
> Дмитрий Тимохов (23.10.10 00:49) [18]
>
> У каждой СУБД свои тонкости, с MS-SQL не работал, ничего
> сказать не могу.

Буду ждать )

По моим сведениям serializable для MS-SQL при десятках чтений (пусть и легких) в секунду штука жесткая.

Интересно опыт подчерпнуть.

← →
vuk © (2010-10-23 01:16) [21]

А у нас на документы просто так менять нельзя. Ну то есть определенные изменения возможно только в определенных состояниях. В некоторых - невозможны вообще. Плюс на время изменения блокировка уровня приложения ставится. Поэтому если кто-то еще захочет поменять - будет послан.

← →
vuk © (2010-10-23 01:17) [22]

>у нас на документы
"на" - лишнее. Нелинейный монтаж текста. :))

← →
Дмитрий Тимохов (2010-10-23 01:20) [23]

> vuk © (23.10.10 01:16) [21]
>Плюс на время изменения
> блокировка уровня приложения ставится. Поэтому если кто-
> то еще захочет поменять - будет послан.

Шо за блокировка?

PS У меня полно всяких оптимистических и пессимистических блокировок. Но есть ощущение, что все уже украдено до меня.

← →
vuk © (2010-10-23 01:30) [24]

sp_getapplock

http://msdn.microsoft.com/en-us/library/ms189823.aspx

Грубо говоря, оно ничего в базе не блокирует, но позволяет "сказать", что мы заблокировали некий виртуальный ресурс. Блокировки бывают на сессионные и на транзакцию. Из клиента делаются сессионные блокировки. Если что-то должно быть заблокировано из хранимой процедуры (ну, например, действия над одним документом приводят к изменению другого), то используется блокировка до конца транзакции (будет предпринята попытка заблокировать второй документ).
Естественно, в обход таких "блокировок" можно сделать все, что угодно, достаточно писать код, который не будет их использовать.

Тху! опять очепятки!!! Праститя-извянитя, я не специально... :)))

> vuk © (23.10.10 01:16) [21]
>
> А у нас на документы просто так менять нельзя.

У вас реально получить квитанцию на товар, который реально отсутствует на складе. По крайней мере можно было несколько лет назад. Я создавал топик и тут и на форуме Ф-Центр. Если исправили или нашли вора, то вам 5.

to Германн © (23.10.10 02:25) [26]:
Я, кажется, тогда сразу подробно отвечал. Если тогда было не понятно то могу объяснить еще раз, хотя и не вижу смысла. Получить квитанцию можно на любой товар, который числится в наличии. Коллизии по данным при этом исключены внутренними механизмами а возможности поставить произвольное количество в строчку наличия в базе нет ни у кого. И с тех пор ничего не изменилось, ошибок в данной части системы как не было, так и нет. А вот человеческие ошибки разного рода на складе, они как были так и есть, и от них избавиться не вышло еще ни у кого.

> А вот человеческие ошибки разного рода на складе, они как были так и есть, и от них избавиться не вышло еще ни у кого.
+1
у нас тоже была 1С-ная конфигурация, в которой именно из-за этого сделали возможность "продаж в минус"/а также возвратов, заказов, т.е. суть. без этого есть возможность завести процесс в "ступор" т.к. "ну как же не могу отгрузить если оно вот у меня в руках". а с этим получаются накладки при введении неправильных данных. т.е. одного йогурта в базе 12, другого -12, на складе 0. и тот самый кладовщик который принял "пересорт" и не уведомил оператора/не исправил накладную, громче всех кричит о глюках в программе (не принимать как намек на Германн-а). парадокс...

← →
Дмитрий Тимохов (2010-10-23 12:53) [29]

> vuk © (23.10.10 01:30) [24]
>
> sp_getapplock
>
> http://msdn.microsoft.com/en-us/library/ms189823.aspx

Угу, Алексей, благодарю. Пойду нашего базаданщика спрошу, почему не используем это, а свой механизм.

Может т.к. у нас до сих пор MSSQL-2000 (клиентов не хотим заставлять покупать новую версию). У вас какая версия сервера?

to sniknik © (23.10.10 12:53) [28]:

> т.е. одного йогурта в базе 12, другого -12, на складе 0.
> и тот самый кладовщик который принял "пересорт" и не уведомил
> оператора/не исправил накладную, громче всех кричит о глюках
> в программе (не принимать как намек на Германн-а).

У нас в минус уйти ничего не может принципиально. Там могут быть другие проблемы - например, накосячили при приеме и комплектации внутренних перемещений, поставок (хотя, последнее бывает крайне редко, на центральном складе контроль достаточно жесткий) и т.д. Или там закатилось на складе куда-нить за стеллаж и в результате когда хотели выдать - не нашли. В конце концов, могут просто спереть.

to Дмитрий Тимохов (23.10.10 12:53) [29]:

> Может т.к. у нас до сих пор MSSQL-2000 (клиентов не хотим
> заставлять покупать новую версию).
>

Если мне память не изменяет, то это и в 2000 есть.

> У вас какая версия сервера?

Сейчас вроде перешли на 2008 R2. Но нам проще, мы сами себе клиент.

> У нас в минус уйти ничего не может принципиально.
там тоже так можно было, если включить "жесткий контроль остатков", но тогда при автоматическом списании при продаже по кассе, и нуле в остатке касса "встанет". практически не использовалось, т.к. даже при изначальном "мы будем строго следить", после пары накладок моментально выключалось.
системы все таки разноплановые, на складе может так и можно, но не в магазине.

я про другое, человеческий фактор, то что люди почему-то первым обвиняют программу, и даже просмотр движения товара, суммирование цифр вручную их не убеждает... им проще верить что программа глючит, чем признать что сами "накосячили"/"прое...".

> люди почему-то первым обвиняют программу, и даже просмотр
> движения товара, суммирование цифр вручную их не убеждает.
> .. им проще верить что программа глючит, чем признать что
> сами "накосячили"

Ох, знакомо...
:o)

← →
Дмитрий Тимохов (2010-10-23 16:45) [33]

> Sergey Masloff (22.10.10 22:50) [1]

У тебя сервер какой?

← →
Sergey Masloff (2010-10-25 10:39) [34]

Дмитрий Тимохов (23.10.10 16:45) [33]
>У тебя сервер какой?
oracle 10.2.0.4 ;-)
я думал что select for update это из стандарта sql но судя по http://stackoverflow.com/questions/1483725/select-for-update-with-sql-server/1483741 это не так

Несостоятельное чтение в СУБД на SQL Найти похожие ветки