expla
Неправильно понимаешь. Нормализация, это устранение аномалий обновления данных при МИНИМАЛЬНОМ числе отношений. А ты тут понахреначил... в 3 раза больше чем нужно.

То чем ты занимаешься, это выделение атрибутов необязательных для заполнения в отдельные таблицы. Приём относящийся сугубо к реализации БД, который по необходимости применялся для экономии места к прямоугольным таблицам-файлам, в которых размер полей и записей фиксированный. В современных БД пустые поля почти (а иногда и совсем) не занимают места, и экономить тут нечего.

sp
даже контактные телефоны - это не одно и то же у них у всех, т.к. назначение у них в принципе разное: на предприятии это - секретарь, рабочий, факс, а для лица - домашний, ну и т.д.

И как Вы себе представляете единую таблицу с аттрибутами и ФизЛица И ЮрЛица и ЧПФЛ? - или необходимо как в той пьесе - тут мы не читаем, тут мы рыбу заворачивали, а тут ваще ничего не надо!? )

А что тут представлять то. Просто таблица со всеми этими атрибутами. Так СУБД Оракл поступает, когда в одной таблице должны храниться разнотипные объекты.

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

[quot expla2. Я не говорю, что хранение разнотипных объектов в одной таблице, это просто как 0. Иначе бы Оракл не стал делать объектную опцию для своей СУБД. Но это вполне нормальный приём, который применяет даже гигант индустрии Оракл. Во всяком случае в реляционной БД, заводить отдельную таблицу для объектов каждого типа и ещё одну таблицу для их общих атрибутов, унаследованных от базового типа, сложнее, чем рулить одной таблицей.[/quot]

Вы можете без теоретических выкладок на данном простом примере проиллюстрировать Вашу мысль?

expla
Но можно и так.




но ведь и при такой реализации (которую я и использовал, но не до конца) просле того как приложение запущено уже неважно что там больше joinov

Dogenexpla
Но можно и так.


По ситуации. Я бы <атрибуты типа Лицо> лучше выкинул. Да Вы сами подумайте, какие там атрибуты могут быть :) ИНН и т.п.? Лучше в раздельных таблицах это держать, чем в атрибутах Лица. В крайнем случае создать еще таблицу Налогоплательщик и внести туда :)

а в догов в поле ДругаяСторона что вы вставлять будете???

explaspно ведь и при такой реализации (которую я и использовал, но не до конца) просле того как приложение запущено уже неважно что там больше joinov

Лишие join'ы сильно влияют на производительность системы. Но выбор реализации конструкции наследования типов выходит за рамки данного форума. Нужно смотреть на конкретную СУБД и другие технические показатели, как то объём данных, методы доступа к таблицам, требования к производительности и д.р..

Ведь можно забить на ссылочную целостность и сделать так:


где ID заполнять из общего счётчика. И т.д. и т.п. На самом деле ссылка из Договора на Лицо не есть лучшее решение. По сути, эта ссылка вычисляемая, если непосредственно в Договоре указаны реквизиты сторон. Если ограничиться только ссылками, такое вычисление должен будет выполнять оператор, который заводит договор. Если в договор включить реквизиты сторон, то такое вычисление может сделать машина и сохранить результат для дальнейшего использования. При изменении даных Лица, машина сможет проконтролировать и пересчитать ссылки, сообщить о том, что в договор нужно внести изменения.

А вот эта идея мне кажется стоящей для рассмотрения, на первый взгляд она может решить все проблемы, но необходимо посмотреть внимательней