Немного флейма,...))

Имеем три таблицы - Dogovor (Договоры), Client (клиенты), Document (Документ клиента (паспорт) удостоверяющий личность). Каждый договор должен быть подписан клиентом, Каждый клиент может заключить много договоров. В каждом договоре, при распечатке должен быть указан паспорт или другой документ удостоверяющий личность клиента. Известно, что клиент может сменить фамилию. Но интересно получать всю историю о конкретном клиенте. Если поместить атрибуты ФИО в таблицу Client, то получится что на одного клиента приходится несколько записей, и историю работы с клиентом сформировать будет невозможно. Опять же, если поменять ФИО в таблице Client, то распечатать договор в том виде, в котором он был до получения клиентом новой фамилии также будет невозможно. Еще одна мысль - чтобы внести клиента в базу необходимо убедиться в его личности - т.е. необходим документ, удостоверяющий личность. Т.е. без паспорта - никуда... Но странное дело большинство систем построено по стандартной схеме, когда атрибуты ФИО b id клиента лежат в одной таблице. А как на счет того, чтобы отойти от этого стандарта?
Например сделать так:


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

Так что же получается? Помнится недавно был топик как однозначно идентифицировать личность. Предлагался вариант ФИО+ДР... А может ну его нафиг такой вариант? потому как в этой схеме он просто не нужен...

Да здравствуют составные первичные ключи!!!!

funikovyuri gardenman


если этот document_id это id документа клиента, возможно, будет достаточно только его?

Ага, я это прекрасно понимаю. Но... т.к. есть внешний ключ от таблицы Dogovor к document, то такой индекс имеет право на существование в целях повышения поизводительности обработки внешнего ключа. И, далее если если к договору прилеплен определенный клиент, то в качестве док-та удостоверяющего личность может быть толь док-т, принадлежащий этому клиенту, либо никакого документа. Короче все до тривиальности просто.

funikovyuri gardenman

Я все взвесил - получается здорово... :) Мой респект!

Глазам не верю! обычно все что я тут говорю в форуме - воспринимается в штыки...

Испытываю чувство глубокого удовлетворения...

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

Вот еще один пример: усть будет табица, содержащая 3 поля - Фамилия, Имя, Отчество. И, допустим требуется реализовать скролируемый просмотр этой таблицы в алфавитном порядке на экране пользователя, причем не загружая всю таблицу (которая может содержать миллионы строк). А испоьзовать для повышения производительности кэширование (строк эдак по 20-50).
Понятное дело, что запросы тапа
select * from people where family >= :f and name >=:n and otch >=:o
абсолютно бесполезны.
В оракле, например, можно создать индекс от функции f(family||name||otch),
эту проблему, или index-organized table по полю family||name||otch, которая будет меняться триггером и служить индексом для основной таблицы. А как быть в других базах? Вот и приходится извращаться - типа создавать вычисляемое поле (family||name||otch), и по нему уже строить индекс. Если смотреть со стороны теории, то тут нарушены все нормальные формы, но зато - работает офигительно быстро.
Вывод - теория хорошо, но опыт - лучше...
И нормализация - это не цель проектирования...
Цель проектирования - производительность и согласованность (непротиворечивость)