Нормализация базы данных для адресов

Question

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

В основном выглядят адреса филиалов и драйверовнапример: address_line_1, address_line_2, город, штат, почтовый индекс, страна

Моя проблема связана с заказами и адресами клиентов.Они должны выглядеть следующим образом: address_line_1, address_line_2, город, штат, почтовый индекс, страна, address_type_1 (дом, бизнес), address_type_2 (пикап, выпадение - это необходимо включить только для заказов).

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

Я должен отметить, что каждая запись будет идентифицироваться с уникальными идентификаторами.Пример:

идентификатор клиента - 10 000 - 99 999

идентификатор заказа - 100 000 - без ограничений

идентификатор водителя - a1 - a999 (возможно)

идентификатор партнера- 1 000 - 9 999

Это всего лишь примеры, поэтому не тратьте много времени на их понимание.

Сколько таблиц адресов мне следует использовать для создания хорошей нормализованной базы данных?

В данный момент у меня на уме три идеи:

1. Одна таблица адресов со всеми включенными полями плюс дополнительная, описывающая тип адреса (клиент, заказ, партнер,Водитель).Не совсем так.

2. Две таблицы адресов.Один с водителями и филиалами, а другой с клиентами и заказами.Для второй таблицы у меня есть и поле, которое всегда будет NULL для клиентов.Не нравится этот тоже.

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

У кого-нибудь есть совет относительно этих трех вариантов или, может быть, даже лучший вариант?

Большое спасибо.

ОБНОВЛЕНИЕ:

Пока не беспокойтесь о системе нумерации для идентификатора таблиц.Это был просто пример.У меня все еще не было времени, чтобы выяснить лучшую систему нумерации.Я доберусь до этого, как только у меня будет проблема с адресами.

Из ответа Мэтта я испытываю желание оставить таблицы драйверов и партнеров с включенными адресами и просто как-то разобраться с таблицами клиентов и заказов.

Для клиентов мне определенно понадобится таблица адресов, потому что у клиента может быть несколько адресов (домашний, бизнес1, бизнес2, избранные места и т. Д.), Которые я хочу сохранить в своем профиле для более легкого доступа.

Я забыл упомянуть кое-что о таблице заказов, которая может немного изменить уравнение задачи.Для любого заказа мне понадобится место для погрузки и выгрузки.Но это может быть либо адрес (улица), либо аэропорт.Это означает, что поля, связанные с адресом улицы, не могут соответствовать конкретным полям аэропорта.Поэтому я уверен, что наличие четырех сущностей (pu_address, pu_airpot, do_address, do_airport) внутри таблицы (все со своим конкретным полем) оставит меня в неиспользуемом пространстве и с программным беспорядком.Пример: для полей подбора: Address_type, Address_line_1, ..., штат, страна, аэропорт, авиакомпания, Flt нет, ... и для возврата то же самое, что пикап.

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

ОБНОВЛЕНИЕ Еще раз спасибо, Мэтт.Во-первых, да, я буду хранить адреса в отдельных полях.Проблема все еще остается для заказов.Я приведу пример, какой тип пу и лимузин использовать.Адрес: 123 Main Street, Чикаго, Il, 60640;Аэропорт: ORD, AA, 123. Мне нужно, чтобы все эти поля были как-то интегрированы в таблицу.

Опции:Таблица заказов

order_id, ..., поля подбора, в которых должны быть поля как для аэропорта, так и для адресов, поля для ввода с полями как для аэропорта, так и для адреса.

Эта опция все еще не работаетЗвучит правильно.

Далее будет две дополнительные таблицы.Один будет для адресов (включая поле для распознавания посадки или высадки).Другой - для аэропорта (с полем для pu или do).

Мне также не нравится эта опция, потому что мне нужно будет выполнить два запроса, чтобы получить информацию только длязапись заказа.Сначала я получу информацию о заказе, а после того, как узнаю тип посадки и высадки (аэропорт или адрес), я сделаю еще один запрос, чтобы получить конкретную информацию о посадки и высадке.

Итак, еще раз ... что я делаю не так?Я что-то пропускаю?

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

Answer 1

Сейчас, наверное, слишком поздно, но я бы предложил 1 Addresses стол (address_id, address_line_1, address_line_2, city, state, zipcode, country, address_type(От FK до AddressTypes таблица)), поскольку это будет соответствовать стандартным правилам нормализации.Ваша таблица Orders будет иметь два отношения внешнего ключа с таблицей Addresses - pickup_address_id и delivery_address_id.У меня есть вопросы по поводу дизайна таблиц Customers, Drivers и Affiliates, но без лучшего понимания того, как они соотносятся, трудно назначить решение.

Одним из вариантов (но я не знаю, подходит ли он вам) будет таблица Parties (party_id, party_type), которая создает отношение супертип / подтип (один к одному или ноль в каждом случае) с Customers, Drivers и Affiliates, все из которых являются типами Party.Я предлагаю прочитать одну или две из статей Дэвида Хэя о моделировании данных для лучшего понимания.

Answer 2

Я на самом деле работаю в сфере верификации адресов с SmartyStreets , где обработка и хранение адресов является нашей областью компетенции.По своему опыту я видел ряд ситуаций, похожих на вашу.

Меня изначально интересуют ваши сегментированные идентификационные номера в зависимости от типа записи.Если четыре типа записей («Клиенты», «Драйверы», «Филиалы», «Заказы») хранятся в разных таблицах, зачем нужны пределы диапазона идентификаторов? (Обновление: на самом деле это не основная проблема ...)

Теперь немного о дизайне базы данных.В идеале ваш дизайн должен отражать работу вашего основного домена (то есть координировать клиентов, заказы, драйверы и т. Д.), Не будучи привязанным просто к адресным данным.Хотя адреса могут быть важными, они не являются основной операцией вашего бизнеса.Исходя из этого и исходя из того, что я почерпнул из вашего исходного поста, я бы сразу же не стал хранить адреса отдельно от реальной записи.

Несмотря на то, что в каждой таблице у вас будут похожие поля, они представляют разные бизнес-цели, и вы не рискуете использовать неиспользуемые ненужные поля. Так что вопрос не в том, «как»1015 * многих адресных таблиц я делаю, "это больше вопрос даже создания любых таблиц только для адресов.

Хотя адреса бывают разных форм и форм, это важно длякомпания-лимузин должна иметь правильную информацию об адресе и нормализовать вашу базу данных.USPS (я предполагаю, что вы находитесь в США) сертифицирует определенных поставщиков для предоставления услуг по нормализации адресов.Это называется CASS ™ Certification.Проведите каждый адрес через службу CASS ™, и все готово.Адреса будут выглядеть одинаково, иметь полную информацию и быть также доставляемыми.Я предлагаю вам начать поиск с чего-то вроде LiveAddress , который будет проверять адреса в точке входа, или Служба очистки списка CASS , которая будет проверять пакет адресов сразу(и предупреждает вас о дубликатах).

ОБНОВЛЕНИЕ: В случае нескольких адресов, которые может иметь клиент, тогда да, я бы рекомендовал использовать для этого отдельную таблицу.Однако вы все равно захотите стандартизировать / проверить их с помощью CASS, поэтому при необходимости вы сможете извлечь дубликаты позже (плюс вы будете знать, что адреса действительно существуют).

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

Для дальнейших вопросов или указаний я могу лично помочь.

ОБНОВЛЕНИЕ

Об отделении адресов от аэропортов: это потенциально допустимое различие в зависимости от потребностей вашего бизнеса, но помните, что у аэропортов тоже есть адреса.Вы можете добавить в свою таблицу поле для хранения названия фирмы или местоположения, на которое указывает адрес, например «Международный аэропорт О'Хара».Это может объединить несколько полей.Кроме того, я предлагаю вам сохранить адрес в отдельных полях по компонентам (улица, город, штат, почтовый индекс и т. Д.).