Я не знаю, как иметь внешний ключ в таблице адресов, чтобы точно определить, к чему он принадлежит, потому что внешний ключ может идентифицировать или букву, или человека.
ЭтоПохоже, вы ошиблись.В таблице адресов не будет внешнего ключа;вместо этого таблица букв будет иметь внешний ключ, ссылающийся на таблицу адресов, а таблица персон также будет иметь внешний ключ, ссылающийся на таблицу адресов.
В SQL представление REFERENTIAL_CONSTRAINTS в каталоге информационной схемы сообщит вам, какойтаблицы ссылаются на таблицу адресов.
В нашем магазине мы регулярно обсуждаем, должен ли адрес моделироваться как отдельный объект.Проблема с обработкой адреса как объекта заключается в том, что нет надежного ключа, кроме самих атрибутов (почтовый индекс, название дома или номер и т. Д.), И многие варианты могут идентифицировать один и тот же адрес (я могу написать свой домашний адрес двадцатью разными способами).,Тогда вам нужно рассмотреть почтовые ящики, заботу об адресах, Санта-Клауса и т. Д. И большой вопрос: разрешаете ли вы вносить изменения в адрес?Если кто-то перемещает дом, сохраняют ли они один и тот же объект адреса с измененными атрибутами (таким образом, все связанные объекты получают изменение адреса), или вы блокируете атрибуты адресов и принудительно создаете новый объект адреса, а затем повторно связываете все адреса ссылокна новый (и удаляете ли вы теперь потерянную адресную сущность, и если да, то почему вы потрудились заменить его ...?) Но в вашем приложении все еще необходимо разрешить изменение адреса в случае, если почтовое отделение изменит егов реальной жизни, но как вам предотвратить использование этой способности, то есть использовать ее для вышеупомянутых незаконных перемещений дома?Вы можете использовать веб-сервис для очистки ваших адресных данных, так что это правильно, но внешний системный способ содержит менее чистые данные, и, следовательно, вы больше не можете сопоставлять свои адресные сущности ...?
Мне нравитсяне усложняйте: адрес - это отдельный атрибут, представляющий собой открытый текст, который вы должны поместить на элемент почты, чтобы он был доставлен почтовым отделением к адресуемому объекту;это не сущность сама по себе, потому что ей не хватает идентификатора.По практическим причинам (например, возможность печатать его на адресной метке) этот единственный атрибут обычно разбивается на субатомные элементы (address_line_1, address_line_2, ... postal_code и т. Д.).
Поскольку в большинстве продуктов SQL отсутствует поддержка доменов, у меня нет проблем с дублированием имен столбцов, типов данных, ограничений и т. Д. Для каждой таблицы, которая моделирует адресуемую сущность.