Crip авторПишете в отдельную ли таблицу, либо поле таблицы с билетами количество забронированных на оформление билетов. И все. Чтобы узнать, сколько билетов осталось, нетрудно понять, что нужно из Доступного количества отнять Забронированное количество. После того, как билет оформлен, соответственно уменьшаем цифру в Доступном и забронированном количестве. И тоже все. Вообще никаких грязных чтений, блокировок и ничего страшного.
А если задачу усложнить. Допустим решается задача складского учета. Списывается товар со склада. Причем при списании нужно узнать учетную (себестоимость) цену товара расчитываемую по методу ФИФО, ЛИФО или средних. При этом возможны правки "задним" числом.
Опять же используется дополнительная таблица хранящая остатки в учетных ценах для каждой строчки документа. Ну например для Накладной №5 строчка 3 списывается 5 банок огурцов, из них 3 приходили по 10руб, а 2 по 5 руб. В MSSQL тут без блокировок ни как, так как при правке задним число все может поменяться то есть допустим стать 5 банок по 4 рубля.
А как в Oracle? Я так понимаю требуется совершенно другая архитектура.
Вопрос задан сугубо из познавательных целей, в Oracle я полный профан.

Какая разница, какая у СУБД архитектура?..

Скорее всего Вам придется озаботиться каскадным пересчетом себестоимостей в документах.

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

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

По моему мнению, архитектура такой системы сильно зависит от бизнес-процесса. Если же Вы собираетесь делать тиражируемое решение, то объем работ будет очень большой.

Crip авторПо моему мнению, архитектура такой системы сильно зависит от бизнес-процесса. Если же Вы собираетесь делать тиражируемое решение, то объем работ будет очень большой
Ну это я и сам знаю. В данном случае шла речь только о автоматическом формировании партий, а зачем это бизнесу вопрос не стоял. Просто хотелось услышать как решается вопрос поддержания целостности данных при такой постановке задачи в Oracle.

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

Если я не прав, то о какой целостности идет речь???

Crip2tygra
Так изменение одной накладной подразумевает каскадное изменение таблицы остатков, при этом другие пользователи также эту таблицу обновляют...

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

Естественно, обновлять надо с блокировкой записей об остатках - ну так select for update вам должно помогать, нет? Вообще можно это на последовательных транзакциях сделать, если делать все быстро то никто и не заметит.

gardenmanЭто ничего если я вмешаюсь?
Обычно я вот так вот (буду в синтаксисе оракла писать) :

не делаю, делаю проще:
При этом абсолютно пофиг какой уровень изоляции или режим выполнения транзакций установлены. Все равно, перед внесением изменений запись сначала заблокируется. В сущности я ниже написал то же что и выше, тока короче. Единственное что в Оракле нужно делать явно - так это COMMIT.
Аналогичная ситуация в DB2. (в DB2 и в Oracle транзакции начинаются неявно, но завершаются всегда явно, - типа промышленные субд все-таки).
А вот в MSSQL, Sybase, если явно не сказал BEGIN TRAN, то и COMMIT делать не обязательно, потому как всякая операция там - атомарна. Поэтому можно просто бахнуть:
В любом случае перед такой операцией нужная запись будет блакирована, обновлена, и разблокирована. И никаких катаклизмов не случится. И никаких потерянных изменений. И ничего повторно считывать не надо. И абсолютно пофиг какой уровень изоляции.

Я охреневаю и умолкаю Живите в своем мире DIRTY READ.