Кроме всего выше сказанного,

достаточно часто потребность в "версионности" неоправданна (точнее, обычно задача понимается неправильно)! Например пусть есть квитанция какой-то формы. Я так понимаю у нее есть поля типа адрес клиента, его имя ну и что-то еще. Так вот - дело в том что в данной ситуации никакой версионности скорее всего не нужно - просто нужно понимать что атрибутом данной квитанции является не ссылка на клиента - а фактические данные по этой ссылки на момент создания квитанции! Т.е. смотрите на поле квитанции "адрес клиента" как на собственный атрибут квитанции! Т.е. квитанция некогда не будет следить за изменениями клиента, наоборот, она зафиксирует данные во время своего создания и они, после этого, станут ее частью!

Теперь насчет "версионности" - это отдельный разговор и потребность в ней обычно вытекает из функциональных требование к ИС. Например, если в них явно указано, что требуется вести историю изменения реквизитов клиента.

zz

Я понимаю чего вам хочется добиться, но на самом деле сейчас вы, возможно, подменяете одну задачу другой. Подумайте над тем что действительно происходит при создании квитанции. Фактически создается новый объект со своими атрибутами и этот объект не планирует меняться вместе с изменением объектов на основании которых он был построен - потому что он - это нечто новое. Проще всего это представить если думать не об абстрактной квитанции а об ее бумажном эквиваленте.
Например -
вы получили права на машину - где указано что машина черного цвета
вы перекрасили машину в красный
следуя вашей логике в ваших правах цвет машины должен поменяться на красный, но это не так - так как в задачу прав не входит обеспечивать кого-либо актуальной всегда информацией - вместо этого они просто сообщают о состоянии дел на какой-то конкретный момент!

На самом деле можно много примеров привести на эту тему - но все они будут сводиться к тому что задача была подменена. Надо было хранить информацию о квитанции - а вместо этого вы стали хранить историю изменения объектов на которых она была основана! В итоге вы получили усложнение базовых объектов (например, клиента), а также усложнили процесс создания отчетов. Т.е. фактически вы размазали процесс формирования квитанции по времени - так как она у вас не храниться в БД, а , в общем-то, формируется каждый раз по требованию. ИТОГ: вы пришли туда же - но другим, более сложным, путем!

Теперь насчет нормализации - как вы уже должны были понять она в данном случае не причем - так как никаких функциональных зависимостей вы не получили (так как id клиента и адрес клиента теперь полностью независимые атрибуты). Если для вашей задачи необходимо оптимизировать способ хранения квитанций - делайте это (опять же к нормализации это отношения уже не имеет - т.е. не все что повышает эффективность БД - является нормализацией :))

zz

Следуя вашей логике, я должен 10 раз вбить его от руки в квитанцию.

Зачем же - вы берете информацию о клиенте их соответствующего справочника и используете ее, для того чтобы создать новую квитанцию! На этом связь и заканчивается. Т.е. в "связь" существует в момент создания и только

zz


Плюс к тому, в случае ошибки оператора...
Таков мир - если у человека в паспорте перепутают место жительства ничего страшного у страны не случиться - только у этого человека

Повторюсь еще раз: а не приведет ли это к неоправданному раздуванию таблицы "Квитанция"?

Приведет - и если это для вас критично - оптимизируйте схему хранения квитанции (например, разнеся ее в разные таблицы)

PS> нет идеальных решений - все они - как и указанное мной - компромиссы - на этом и стоим :)