В развитие данной темы...

Как я описывал, у меня возникли "идейные" разногласия по структуре проектируемой БД с окружающими меня "специалистами". Поскольку к согласию мы не пришли, то ими была разработана "альтернативная" структура БД, в которой я увидел моменты, где идея нормализации, на мой взгляд, была доведена до абсурда.
В частности, информация о людях описывается следующим образом:
Есть таблица fio, каждая строка которой представляет отдельного человека. Из этой таблицы имеется 3 ссылки по вторичным ключам на три отдельные таблицы, каждая из которых представляет, соответственно, фамилии, имена, отчества. Предметная область не предполагает лингвистический анализ имен и фамилий :) То есть таким образом описываются обычные клиенты - физические лица.
В качестве аргумента ЗА именно такую структуру говорится "чтобы пользователи не ошибались при вводе одинаковых имен и фамилий".
С адресами та же ситуация:
Есть таблица адресов клиентов, которая (помимо первичного ключа) представляет собой набор вторичных ключей на соответствующие таблицы регионов, улиц, домов, корпусов домов и даже этажей. Причем эти таблицы представляют собой "голые справочники" никак не связанные между собой. То есть, например, в таблице домов "тупо" перечислены номера домов, которые никак не связаны с улицами. Дом 5 на улице Ленина и дом 5 на улице Троцкого, например, будет представлять собой одну запись в таблице домов и два адреса в таблице адресов будут ссылаться на эту запись.
Кроме того есть даже отдельные таблицы для квартир и комнат, при этом также не связанные с другими "адресными" таблицами (домов, улиц и прочего). Зато на эти таблицы имеются ссылки FK из таблицы клиентов. То есть от клиента есть ссылка на адрес (который описывает вплоть до дома), плюс ссылка на квартиру, плюс ссылка на комнату.
Аргументация - "номера квартир в домах повторяются, поэтому лучше их хранить в виде справочника и связь с клиентом делать ссылкой".

У меня всё тот же вопрос - или я дурак и чего-то не понимаю в этой жизни, или... ?

Nafто есть все Ивановы ссылаются на одну запись Иванов?
С уважением, Naf

Да-да. Именно так.

И ссылаются на ту же запись с номером квартиры (допустим 10), на которую ссылаются все другие Петровы, Сидоровы и прочие, также живущие в квартире №10, хоть и в других домах на других улицах :)

NafСколько я понял автора как раз нет, ссылаются не на квартиру, а на номер - то есть все квартиры во всех домах, всех улиц и т.д.
Да-да, именно так.

NafК автору: а какова предметная область БД?
Ну не вдаваясь в детали - "самая обычная":
Автоматизация бизнес процессов коммерческой организации. Организация обслуживает клиентов - физических лиц, выставляет им счета, оказывает им услуги, принимает оплаты. То есть такая "учетно-рассчетная" система.

alexeyvgКак это поможет "не ошибаться при вводе одинаковых имён и фамилий"??? Они хоть сказали? Или они ничего не говорят, бешенно вращают глазами и нормализуют, нормализуют... :-)
Ну говорят, что, типа, при вводе очередного Иванова, пользователю не надо будет заново набирать фамилии, а можно будеть выбрать из "справочника" по ссылке. Тем самым это не допустит возможность опечатки и введения скажем фамилии Ивынов :)

NafЭто...
а пол лица в отдельную таблицу не вынесен? с ссылкой на записи:
мужской
женский
не определился
другое

С уважением, Naf
Как в таких случаях говорится - "ты знал, ты знал" :D
На полном серьезе, вот сейчас смотрю на эту структуру - таблица _dic_sex .
2 поля: 1 - первичный ключ (причем int, видно с расчетом на то, что сексуальная революция продолжит развиваться бурными темпами и значения размером в байт может не хватить :) ), 2 - строковое значение.
Просто ссылка на эту таблицу не из таблицы людей, а из таблицы их удостоверений личности.

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