Нормализация базы данных для адресов
Я пытаюсь создать базу данных для компании по производству лимузинов, и я застрял в том, сколько нормализации мне нужно сделать для адресов, связанных с клиентами, драйверами, филиалами и заказами.
Обычно адреса Партнера и Водителя выглядят следующим образом: address_line_1, address_line_2, city, state, zipcode, country
Моя проблема связана с адресами заказов и клиентов. Они должны выглядеть так: строка_адреса_1, строка_адреса_2, город, штат, почтовый индекс, страна, тип_адреса_1 (домашний, рабочий), тип_адреса_2 (получение, высадка - это нужно указывать только для заказов).
Таким образом, между всеми четырьмя таблицами у меня есть общие черты в адресных полях, за исключением двух полей, которые различаются в таблицах клиентов и заказов.
Я должен упомянуть, что каждая запись будет идентифицироваться с уникальными идентификаторами. Пример:
Идентификатор клиента - 10 000 - 99 999
Идентификатор заказа - 100 000 - без ограничений
Идентификатор водителя - a1 - a999 (возможно)
Идентификатор партнера - 1000 - 9 999
Это просто примеры, поэтому не тратьте много времени на их понимание.
Сколько таблиц адресов мне следует использовать для создания хорошей нормализованной базы данных?
В данный момент у меня в голове три идеи:
Одна таблица адресов со всеми включенными полями плюс одна дополнительная, описывающая тип адрес (заказчик, заказ, аффилиат, водитель). Не очень нравится этот.
Две таблицы адресов.Один с драйверами и партнерами, а другой с клиентами и заказами. Для второй таблицы у меня будет поле и, которое всегда будет NULL для клиентов. Это тоже не нравится.
Три таблицы адресов. Один для водителей и партнеров, один для клиентов и один для заказов. Отсутствие неиспользуемых полей заставляет меня думать, что это может быть лучшим вариантом, чем два других.
Есть ли у кого-нибудь совет относительно этих трех вариантов или, может быть, даже лучший вариант?
Большое спасибо.
ОБНОВЛЕНИЕ:
Пока не беспокойтесь о системе нумерации для идентификаторов таблиц. Это был просто пример. У меня все еще не было времени придумать лучшую систему нумерации. Я перейду к этому, когда решу проблему с адресами.
Судя по ответу Мэтта, у меня возникает соблазн оставить таблицы драйверов и партнеров с включенными адресами и просто каким-то образом отсортировать таблицы клиентов и заказов.
Для клиентов мне определенно понадобится таблица адресов, потому что у клиента может быть несколько адресов (домашний, рабочий1, рабочий2, любимые места и т. Д.), Которые я хочу сохранить в своем профиле для облегчения доступа.
Я забыл упомянуть кое-что о таблице заказов, которая может немного изменить уравнение проблемы. Для любого заказа мне понадобится место для приема и отправки. Но это может быть адрес (почтовый адрес) или аэропорт. Это означает, что поля, относящиеся к почтовому адресу, не могут совпадать с полями конкретного аэропорта.Поэтому я почти уверен, что наличие четырех сущностей (pu_address, pu_airpot, do_address, do_airport) внутри таблицы (все со своим конкретным полем) оставит меня в неиспользуемом пространстве и с программным беспорядком. Бывший: для полей получения: Address_type, Address_line_1, ..., state, country, Airport, Airline, Flt no, ... и для высадки то же самое, что и для получения.
Так что у меня все еще есть проблема с таблицей заказов, по которой я не уверен, как двигаться дальше. Мне нужно, чтобы адреса и места встречи и высадки в аэропорту были включены с использованием дополнительных таблиц или без них.
ОБНОВЛЕНИЕ Еще раз спасибо, Мэтт. Во-первых, да, я буду хранить адреса в отдельных полях. Проблема по-прежнему остается для заказов. Я приведу пример того, какой тип ПУ и лимузинов используют. Адрес: 123 Main St, Chicago, Il, 60640; Аэропорт: ORD, AA, 123. Мне нужно как-то интегрировать все эти поля в таблицу.
Параметры: Таблица заказов
order_id, ..., поля получения, которые должны содержать поля аэропортов и адресов, поля возврата с полями аэропорта и адреса.
Этот вариант по-прежнему кажется неправильным.
Следующим будет две дополнительных таблицы. Один будет для адресов (включая поле для распознавания посадки или высадки). Другой будет для аэропорта (с полем для пу или тоже).
Мне тоже не нравится этот вариант, потому что мне нужно будет выполнить два запроса, чтобы получить информацию только для записи заказа.Сначала я получу информацию о заказе, а после того, как я узнаю тип получения и высадки (аэропорт или адрес), я сделаю еще один запрос, чтобы получить конкретную информацию о получении и высылке.
Итак, еще раз ... что я делаю не так? Я что-то пропускаю?
И да, я обязательно воспользуюсь какой-нибудь системой проверки, чтобы убедиться, что адреса верны.