Кто как работает с Master-Detail записями?

Привет, Народ!

Дикое екскьюзми, если офтопик...

Допустим есть таблица Догорова. У нее есть несколько связанных таблиц - ДопСоглашения, Спецификация, ПротоколыРазногласий и т.п. У ДопСоглашений и ПротоколаРазногласий в свою очередь есть связанные таблицы соответствующих спецификаций. Вот теперь вопрос. Каким образом построить логику приложения, написанного на Delphi к примеру, что бы ввести новый договор? Точнее говоря что должно происходить на вервере, при вызове бланка договора? О чем я? Дело в том, что пользователь, например просле заполнения шапки договора начинает заполнять, к примеру, его спецификацию. У спецификации есть поле IDДоговора, которое должно быть! Кроме всего этого, обязательным условием ссылочной целостности, необходимо сохранять договор со всеми его причиндалами (спецификацией, доп соглашениями и пр.) в рамках единой транзакции! Мне пока очевидны 2 пути построения логики:

1. Не создаем новый договор и работаем с временными таблицами. Т.е. принимаем, к примеру, что код вновь созданного договора равен -1. Создаем временные таблицы для всех подчиненных таблиц и заносим данные в них с кодом договора -1. Потом, при сохранении, сливаем все из временных таблиц в постоянные. Недостатки: много рутинной работы.

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

Ну так вот, кто как выкручивается в подобных ситауциях?

3. Ничего не создаешь на сервере, а при сохранении нового документа (DocId = -1) оптом припишешь все связи.

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

AndyMandy : Состояния документа безусловна важны, но вопрос, на сколько я понял состоит в том, как на самом первом этапе создания нового документа затолкать его в БД с учетом всей существующей целостности ...
Miktor : Мы сохраняем документы в БД не с помощью rs.Post, а с помощью передачи полного XML документа. Процедура, парсит его и раскладывает по всем табличкам. Клиенту пофиг, новый это документ или нет. Это головная боль ХП. Тем более, клиент отвязывается от структуры таблиц.

2 AlexAntonoff

>>Мы сохраняем документы в БД не с помощью rs.Post, а с помощью передачи
>>полного XML документа. Процедура, парсит его и раскладывает по всем
>>табличкам. Клиенту пофиг, новый это документ или нет. Это головная боль
>>ХП. Тем более, клиент отвязывается от структуры таблиц.

А нельзя ли поподробнее где-нибудь почитать про такой подход?

А тут и читать нечего ... Структурируй удобным тебе образом информацию, и передавай ее на сервер. А там OpenXML. Если что спрашивай ...

2Miktor
1 путь

Хоть и много рутинной работы, но реально не так много, по сравнению с остальной работой. И быстро работает.

Путь №2

Машина состояний, состояние "оформляется"
ОЧЕНЬ удобно
Ранее пользовались версиями подхода №1,- убожество
Транзакции В ЭТОМ КОНТЕКСТЕ - тоже убожество, как и временные таблицы
Только машина состояний :)

Доказательство

В реальной жизни договор печатается. Потом таскается по кабинетам и обрастает кучей бумажек / виз. Для того, чтобы его начали "таскать" это сначала вообще кусок бумажки, где от руки написано пара кодов и сумма :) Так что - только машина состояний. Это наиболее гибкий способ и наиболее близкий к жизни. Или к системе внутреннего документооборота. Хотя, в системе ориентированной на голый учет, возможно, все будет иметь несколько другие акценты...

2Crimean

Конечно, машина состояний.
Но состояния-то обычно должны быть допустимые, определённые в системе, подчиняющиеся установленным бизнес-правилам.

И если изменения в документе (в наборе связанных данных в разных таблицах) будут делаться по полю по таблице без транзакции, там через немного времени всё перепутается.

Вот вопрос в том, как делать переход из состояния в состояние.