Как лучше представлять адреса в базе данных

Question

Возможные Дубликаты:
Is there common street addresses database design for all addresses of the world?
What is the “best” way to store international addresses in a database?
Best practices for consistent and comprehensive address storage in a database

Я в настоящее время есть четыре таблицы, клиенты, контакты, Услуги и клиенты.

Каждая из этих таблиц имеет следующие поля: AddressLine1, AddressLine2, City, StateOrProvince, PostalCode.

Я хотел бы переместить адреса в отдельную таблицу и также указать тип адреса (биллинг, доставка, основной и т. Д.).

Мое решение заключается в следующем:

1. Удалить addressLine1, addressLine2, город, StateOrProvince, PostalCode от клиентов, контактов, объектов и клиентов.
2. Создать таблицу адресов с полями AddressID (PK), AddressLine1, AddressLine2, City, StateOrProvince, PostalCode, LastUpdateUser, LastUpdateTime.
3. Создать таблицу AddressTypes с полями AddressTypeID, AddressTypeName, AddressTypeDescription, AddressTypeActive, LastUpdateUser, LastUpdateTime
4. Создать таблицу CustomerAddresses с полями CustomerID, AddressID, AddressTypeID, CustomerAddressActive, LastUpdateUser, LastUpdateTime
5. Создать таблицу ClientAddresses с полями ClientID, AddressID, AddressTypeID, ClientAddressActive, LastUpdateUser, LastUpdateTime
6. Создать ContactAddresses таблицу с полями ContactID, AddressID, AddressTypeID, ContactAddressActive, LastUpdateUser, LastUpdateTime
7. Создать FacilityAddresses таблицу с полем s FacilityID, AddressID, AddressTypeID, FacilityAddressActive, LastUpdateUser, LastUpdateTime

Ищу для руководства, чтобы определить, есть ли лучшее решение, чем я придуманной. Почему все думают?

EDIT: На данный момент меня не интересует ничто за пределами США и не связано с тем, как хранить адрес улицы, то есть номер улицы и весь адрес улицы. Меня беспокоит конструкция базы данных и точка зрения таблицы.

Answer 1

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

1. Удалить addressLine1, addressLine2, город, StateOrProvince , PostalCode от клиентов, контактов, услуг и клиентов.
2. Создать AddressTypes таблицу с полями AddressTypeID, AddressTypeName, AddressTypeDescription, AddressTypeActive, LastUpdateUser, LastUpdateTime
3. Создание Адреса таблицы с полями AddressID (PK), AddressTypeID (FK), addressLine1, addressLine2, город, StateOrProvince, PostalCode, LastUpdateUser, LastUpdateTime , CustomerID (FK), ClientID (FK), ContactID (FK), FacilityID (FK) 4. В таблице адресов настройте ограничение, чтобы только один из внешних ключей CustomerID, ClientID, ContactID или FacilityID мог быть не-NULL за раз.

Таким образом, у вас есть все ваши адреса в одной таблице, они могут ссылаться на любую запись, в которой вы нуждаетесь, ваша ссылочная целостность не повреждена, а у вас нет промежуточной таблицы, которую вы должны пройти.

Недостатком является то, что если вы хотите добавить адреса в новый класс объекта (например, таблицу Employee), вам нужно добавить столбец EmployeeID в таблицу адресов, но это довольно просто.

Answer 2

Я также хочу добавить еще одну вещь, для простоты, создать представления, которые расширяют адресную информацию в ваших таблицах, или вы можете ненавидеть себя за разработку db таким образом.

Answer 3

Я бы рассмотреть таблицу одного AddressLink (название?) С

LinkTypeID (Customer,Client,Contact,Facility) -- needs additional TypeID table 
ID (CustomerID,ClientID...) 
AddressID 
AddressTypeID 
AddressActive 
LastUpdateUser 
LastUpdateTime 

Добавление нового типа адреса ссылки означает добавление нового LinkTypeID ж/оа новый [TypeID] таблицы адресов, никаких запросов должны быть изменен, и если вы ищете все виды использования адреса (для удалений и т. д.), есть только одно место для поиска.

Это похоже на то, как мы это делаем.

О, и у нас есть AddressLine3 в нашей таблице адресов (эквивалентных) для некоторых ситуаций с нечетными выбросами.

Answer 4

Еще одна вещь, которая у нас есть в нашей базе данных, которую вы можете рассмотреть, - это иметь флаг соответствия в таблице адресов с триггером для обеспечения того, чтобы только один адрес на одного человека мог делать ставку в качестве корреспонденции. Мы отправляем много писем людям в нашу базу данных и знаем, какой из трех адресов для этого человека тот, который нам нужно использовать при отправке почты, неоценим. Это также облегчает запрос, чтобы захватить только один адрес на человека, чтобы избежать получения нескольких записей на человека для некоторых отчетов.