MicrobitЗанимаюсь проектированием структуры БД. В соответствие с предметной областью необходимо хранить адреса (людей, организаций) и информацию по почтовым отделениям.
Из житейского опыта все мы знаем, что каждый конкретный адрес "прикреплен" к одному почтовому отделению (имеет один почтовый индекс). При этом каждое почтовое отделение в свою очередь расположено по одному конкретному физическому адресу.
При проектировании БД для данной предметной части я создал соответственно 2 таблицы:
1 - Таблица адресов (A),
2 - Таблица почтовых отделений (P).
Каждая из них имеет свой целочисленный первичный ключ:
pk_A - для адресов, pk_P - для почтовых отделений.
Кроме полей описывающих характеристики каждой сущности (они сейчас не столь важны) каждая таблица имеет вторичные ключи с указанием на строку "соседней" таблицы. То есть таблица адресов имеет вторичный ключ fk_P с указанием на pk_P таблицы P. А таблица почтовых отделений имеет вторичный ключ fk_A с указанием на pk_A таблицы A.
То есть для каждого адреса хранится (может хранится) ссылка на почтовое отделение, за которым закреплен данный адрес. А для каждого почтового отделения хранится ссылка на его физический адрес.
Оба вторичных ключа NULL-допускающие (NULL если почтовое отделение для адреса, или адрес почты неизвестны или не указаны).
Вроде бы всё очевидно (на мой взгляд).

Проблема в том, что окружающие меня "специалисты" (и их большинство) увидев данные "перекрестные" ссылки утверждают, что это "ересь", что так делать неправильно, нельзя и это вообще работать не будет. И хором настаивают на введение третьей "связующей" таблицы.
При этом с аргументацией их мнения дела обстоят не важно. Самый "достойный" их аргумент (и пожалуй единственный), что в этом случае не будет работать каскадное удаление. Я отвечаю, что оно в данном случае не столь важно и даже вредно. Предлагаемые схемы с третьей таблицей представляются мне лишь менее адекватно описывающими семантику описанных связей.По-видимому, всё-таки не вторичные ключи, а внешние ?
Делайте так, как считаете нужным. С практической точки зрения выглядит Ваше решение выглядит вполне убедительно. Насколько я понял из первого топика, любое почтовое отделение имеет адрес(либо он неизвестен), и каждый адрес обслуживается каким-либо почтовым отделением(либо оно неизвестно). Из этого ясно, что здесь получается не одна классическая связь типа M:N со стандартным решением в виде развязки промежуточной таблицей, а две, вполне различные по семантике, связи. Одна 1:M(ПО->обслуживает->Адрес) и вторая 1:1(ПО->имеет->Адрес). Смешивать их в некоей одной промежуточной таблице не выглядит разумным решением. В таком случае для комбинаций (ПО,Адрес) понадобиться отличать адрес, который имеет ПО, от адреса, которое оно обслуживает в случае их совпадения. Для этого придется в такую таблицу добавлять поле, которое позволить описать это различие. IMO, разные по смыслу связи правильнее хранить в разных таблицах, а не запихивать все в одну с добавлением специальных атрибутов для их различения.
В случае нескольких адресов на одно ПО, из таблицы ПО ссылку на адрес надо будет исключить и добавить промежуточную таблицу, в которой будут перечислены ссылки на все возможные адреса для каждой ссылки на ПО. Причем, возможно, стоит рассмотреть возможность нахождения двух или более разных ПО по одному и тому же адресу.