К примеру, имеем документ. Но сам документ не содержит никаких данных, а тоьлко ссылки (много). Его отпечатали, проплатили, положили в шкаф. После этого изменять документ нельзя. И на это есть логика в базе в таблице документов. Тем не менее можно изменить все в подиченных таблицах, на которые ссылается этот документ. И если это случается то меняется и сам документ, при его открытии или печати данные будут другими.

как бороться

Кот Матроскин,

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

guest_20040621,

Проектировал не я:) По делу есть что-то?

vmag,

Тут вообще весело будет, если в таблице одно, а в документе другое. Будут круглые глаза и вопросы "откуда оно там взялось?"

В общем склоняюсь к мысли создать XML колонку в таблице доументов и сохранять документ там в момент его генерации, как xml со всеми данными. Благо Оракел такое позволяет. Остается вопрос про FK документа. На фига они нужны и на что они ссылаются?

Ну или вообще перейти на документo-ориентированные ДБ, типо Монго. Вижу тенденция к тому :) Вот тебе и "учится проектировать БД". То, что мы учили придется забыть.

Кот МатроскинЧто значит "не возможно использовать уникальные ключи" - а какие возможно использовать, неуникальные? :)
Разумеется, ключ таблицы (даже в случае хранения истории в той же таблице, что и актуальные значения, что, вообще говоря, необязательно) будет уникальным, просто сама таблица будет устроена чуть сложнееНу как? Есть в таблице PK (сурогат) и АК (код клиента). Оба уникальны. Если хранить историю тут-же, то с АК уникальность придется снять. Если историю вынести в отдельную, этож как нужно будет переделать модель и прикладнуху....

>> И чем по логике и назначению то что выше отличается от того что ниже

Тоже костыль, но не такой массивный :)

>> Хочется освоить XML ??? Ну, тоже тема...

Все уже давно освоено.

vmag- а на сколько не такой массивный? И в какую сторону?
- ведь вся полная текстовая информация по документу и там и там практически одинаковая,
только в таблице не будет кучи тэгов и разметки которые есть в XML
которые тоже нужно хранить...Над собой смеетесь:) Документ может состоять из 5, 6-ти и даже более подчиненных таблиц -деталей. Я могу это дело загнать в одно XML поле в мастере. Теперь раскажите нам как будет удобно построить "актуальных" таблицы для всех этих деталей?

guest_20040621Вам же сказали, Relic Hunter: учиться проектировать. У любой сущности есть жизненный цикл. Любое подмножество экземпляров сущностей включает значение временной метки. Любая сущность идентифицируется суррогатными ключами. Этого достаточно, чтобы построить логически корректную модель. Берёте карандаш и рисуете зависимости. Отсюда, кстати, просто рисуется и модель регистрации изменений.Там свои проблемы. Как обеспечить не пересечение временных интервалов на уровне таблицы? Если есть "начало" и "конец". Как обеспечить не обязательное значениe (null) поля "конец" только для одной! строки на уровне таблицы?

Реляционными методами такие проблемы не решаются.

придется прямой доступ к таблицам закрыть и писать свой АПИ (процедуры) для доступа к данным.

Кот Матроскин1. Сохраняется состояние не для каждого документа (100 раз в день одно и то же), а тогда, когда одна из сущностей, на которые ссылается документ, меняется
2. История изменений позволяет решать и другие задачи, кроме сохранения неизменного состояния проведенных документов.Ну вобщем, так и делаем. Ведем историю изменений в таблицах. Не идеально, много проблем с данными, о которых я упомянул выше. Пользовательский интерфейс еще тот, сложный и размытый в связи с этим. В общем, не доволен.