Какой была бы лучшая схема для хранения «адреса» для разных объектов?

Предположим, мы создаем систему, в которой мы должны хранить адреса зданий, людей, автомобилей и т. д.

Формат адреса должен быть примерно таким:

State  (From a State list)
County (From a County List)
Street (free text, like '5th Avenue')
Number (free text, like 'Chrysler Building, Floor 10, Office No. 10')

(Да, я не живу в США)

Как лучше хранить эту информацию:

  • Должен ли я иметь Person_Address, Car_Address, ...
  • Или информация об адресе должна быть в столбцах для каждого объекта,
  • Можем ли мы иметь только одну таблицу адресов и попытаться связать каждую строку с другим объектом?

Или есть другой "лучший" способ справиться с этим типом сценария?
Как бы вы это сделали?


sql database schema database-design street-address
person Cesar    schedule 27.07.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

Я также видел это, когда адрес хранится в строке клиента. Это приводит к эффективным массивам адресов для выставления счетов, доставки и т. д., и это нормально. Имея дело с обоими, я думаю, что предпочитаю иметь их в своих собственных объектах, это позволяет вам довольно легко вести историю старых неактивных адресов.

Мы использовали тот же метод для телефонных номеров, где людям нужно хранить различные номера телефонов.

person Cade Roux    schedule 27.07.2009

arrow_upward
1
arrow_downward

Я настоятельно рекомендую прочитать «Шаблоны моделей данных — условности мышления» Дэвида С. Хэя. Этот вопрос подробно рассматривается автором.
В вашем дизайне есть две широкие сущности.

  1. Адрес географического местоположения
  2. Лицо/объект, который проживает/принадлежит адресу

Как правило, не рекомендуется объединять адрес с информацией о человеке или объекте в одной таблице, как показано ниже.

Person(personID, name, gender, addressline1, addressline2)

В вашем дизайне могут быть следующие объекты: 

Address(number, street, countyID,stateID)
Party(PartyID, Type)
Person(PersonID, name, dob, gender,...,primaryPartyID)
Car(carID, make, model, ...,primaryPartyID)

Сторона является связующим звеном между человеком/автомобилем и адресом. Таблицы primaryPartyID лично и Car являются внешними ключами к таблице party. Таким образом, вы можете обмениваться данными и адресоваться между автомобилем и человеком. Если вы хотите сохранить несколько адресов для каждого человека, вы можете добавить отдельную таблицу m:n между человеком и стороной. Атрибут типа для Стороны может принимать следующие значения: «Человек», «Транспортное средство» и т. д.

person bkm    schedule 29.07.2009

arrow_upward
0
arrow_downward

Я бы сказал, что поле AddressType является поиском из раскрывающегося списка.

person David    schedule 27.07.2009