Это хороший способ для моделирования адресной информации в реляционной базе данных?

Мне интересно, если это хороший дизайн. У меня есть несколько таблиц, которые требуют адресную информацию (например, улица, почтовый индекс / страна, факс, электронная почта). Иногда один и тот же адрес будет повторяться несколько раз. Например, адрес может храниться у поставщика, а затем при каждом отправленном им заказе на покупку. Затем поставщик может изменить свой адрес, и любые последующие заказы на поставку должны иметь новый адрес. Это сложнее, чем это, но это пример требования.

Вариант 1 Поместите все столбцы адреса в качестве атрибутов в различные таблицы. Скопируйте детали от поставщика в ПО по мере его создания. Потенциально хранить несколько копий

Вариант 2 Создайте отдельную таблицу адресов. Получить внешний ключ от поставщика и таблицы заказов на покупку к таблице адресов. Разрешите вставлять и удалять только в адресной таблице, поскольку обновления могут измениться больше, чем вы предполагаете. Тогда у меня была бы какая-то запланированная задача, которая удаляет все строки из таблицы адресов, на которые больше нет ссылок, поэтому неиспользуемые строки не остались. Возможно, также есть уникальное ограничение на все столбцы не-pk в таблице адресов, чтобы также останавливать дубликаты.

Я склоняюсь к варианту 2. Есть ли лучший способ?

РЕДАКТИРОВАТЬ: я должен сохранить адрес в заказе на покупку, как это было при отправке. Кроме того, это немного сложнее, чем я предложил, так как это может быть адрес доставки и адрес выставления счета (есть также куча других таблиц, которые имеют адресную информацию).

Через некоторое время я буду массово удалять старые заказы на покупку в зависимости от их даты. Именно после этого я собирался собрать мусор в любых адресных записях, на которые больше ничего не ссылается (в противном случае создается впечатление, что я создаю утечку).

Ответы на вопрос(2)

Ваш ответ на вопрос