Может будет интересно...
Про даты и версии.
Сначало о терминологии.
Версионность - возможность видеть объект (запись, группу записей) на момент времени отличный от текущего,
как правило, в прошедшем времени.
Логирование - возможность видеть кем, когда и как объект был изменен (удален, добавлен).

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

Немного о реализации.
Есть таблица с основными данными, есть с версионными. Таблица с версионными данными имеет поле с датой
актуальности этих данных.
Для версионного объекта, версия создается в момент сохранения (нового, редактируемого) объекта.
Для объекта, имеющего ссылку на версионный, реализация может быть сделана одним из двух способов,
опять же, в зависимости от требований.
Это 1 - выбор версии при сохранении объекта,
либо 2 - выбор версии, при просмотре объекта.
Как пример, версионный объект "Юр.лицо" в документе (ссылка на юр.лицо из документа).
В первом случае, мы всегда будем видеть документ, таким-каким он был.
Логирование, это лишь теневая таблица, в которой регистрируются все изменения,
плюс информация о том, кто когда и откуда их сделал.

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

guest_20040621> Есть таблица с основными данными, есть с версионными.

Алгоритм разделения данных на основные и версионные - в студию.

Это не алгоритм. Это проектирование.

Простой пример. Контрагент.
Основные - ПК (перв.ключ)
Внутренний код
Краткое наименование
Версионные - ПК
ПК_Осн.
Дата актуальности
Полное название
Тип (ОАО, ЗАО,....)
и т.д.

guest_20040621> Это не алгоритм. Это проектирование.

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

> Простой пример

Мне не примеры нужны (тем более примеры с ошибками), а алгоритм. На основании чего и как делается вывод об "обычности" данных и "версионности"?

1. Где в примерах ошибки?
2. Если Вас интересует алгоритм проектирования, пожалуйста. Если значение атрибута (свойство) объекта может изменяться с течением времени, и нужно на конкретную дату видеть его таким, каким оно было на эту дату, тогда версионный атрибут, если оно не изменяется, или его изменение не влияет на бизнесправила, тогда простой.

guest_20040621> Если значение атрибута (свойство) объекта может изменяться
> с течением времени

А теперь расскажите, какие атрибуты не могут изменяться с течением времени.

Уважаемый guest_20040621, не нужно выдергивать фразу из предложения, и задавать по ней вопрос. Если Вас что-то по данной теме интересует, формулируйте вопрос конкретней, а не разводите полемику.

p.s.
с течением времени, не может изменитсья, к примеру, дата рождения (исключая ошибочный ввод)

guest_20040621Дружище, сильно вряд ли Вы скажете что-то такое, чего я бы не знал.
От чего такая уверенность?
guest_20040621Т. е. Вам ахинею нести можно, а мне вопросы задавать нельзя?
И где я нес ахинею? Хотя Вам никто не запрещает...
guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. Еще варианты?
Читайте выше "Исходя из бизнес-требований..."

softwarer guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды.
И каким именно образом это сделает эти данные версионными? Ну и заодно любопытно было бы посмотреть на машину времени, которая определит эти данные например для меня :)

А вдруг изобретут! И будут разные релизы этой машины, и надо будет править дату, после каждого релиза, и хранить эту историю :) )

guest_20040621> Читайте выше "Исходя из бизнес-требований..."

Что это за алгоритм "бизнес-требование"? Своими словами, пожалуйста.
Бизнес-требования это не алгоритм, а документ, который содержит информацию (требования к бизнес-процессам в частности.), используемую при проектировании информационной системы.

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