doofyЕсть, предположим, табличка "Документ", и много справочников. Эта табличка содержит ссылки на справочники.
И вот если какой то из них будет изменен, то старые данные на которые ссылался этот "Документ" будут потеряны(ведь у нас там только ссылка а данные в справочники поменялись)...
Как же сделать так, чтобы эти данные никуда не пропадали при изменении справочников.

Я для себя вижу два варианта:
1) Сказать пользователю, что мол нельзя так делать и надо создавать новый справочник
2) Дублировать поля справочников в "Документе" и при создании "Документа" копировать просто инф. из справочников.

Может чота не понял, но по-моему все классически просто: в таком случае (при изменении справочника) делается не прямой апдейт записей, а текущая запись становится архивной (например проставляется дата архивации или поле-признак), и добавляется новая запись, т.о. все записи документов будут ссылаться на прежние данные, а для новых документов выводим только текущие актуальные записи справочника.

Уважаемый автор Плохое решение!
Например, клиент поменял название юридическое, а взаиморасчеты надо строить фактически по клиенту. Усложняются выборки и связи в отчетах и т.д.
Второй пример, сотрудница вышла замуж и сменила ФИО. Заводить нового сотрудника не верно! Как учитывать в расчетах прежние начисления?

поэтому, только механизмы учитывающие периодические изменения!
выше структуру приводил!

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

2. в то же время:
Уважаемый авторвведите таблицу "история изменений"
- id
- id записи ваших таблиц
- имя поля
- старое значение
- новое значение
- дата, время изменения
Именно такой вариант приемлем, если в целом данные хранятся в базе развернутые "вертикально" (имя поля - значение), таких систем мало встречал, как и систем с таким механизмом историчности. Если же данные хранятся "горизонтально" (таблицы не из двух полей :), то для поддержания историчности типа "имя поля-старое значение-новое значение" придется довольно капитально перепиливать систему, практически все отчеты, с вероятностью 99%, придется переползать переползать на динамический скл, что совсем не делает систему внутри удобочитаемой, да и по быстродействию просядем немного.
А так да, отдельная табличка - вполне нормально, не спорю.

Уважаемый авторвведите таблицу "история изменений"
- id
- id записи ваших таблиц
- имя поля
- старое значение
- новое значение
- дата, время изменения

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

Ivan DurakНу документ выписанный год назад не должен при сегодняшнем просмотре на него ОТЛИЧАТСЯ, от своего состояния годичной давности. Так что в нем как раз и должно быть старое наименование!
Там речь не о документе, а о взаиморасчетах - т.е. в отчете мы должны условно подбить баланс по одной организации, хотя у нее уже типа две записи, поэтому речь о том, чтобы основная запись клиента всегда была одна, но с историей изменения, в документах отображать исторические данные, но иметь сущность, которая бы отражала организацию в целом для удобства тех же взаиморасчетов )