Нормализовать или не нормализовать

Question

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

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

Существует другое мнение, что все адреса должны быть в одной таблице.

Я использую PostgreSQL и просматриваю более 10 миллионов записей.

Как вы думаете, что лучше дизайн?

С нетерпением жду вашего мнения.

С уважением,

Shardul

Answer 1

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

10 миллионов записей - это неуправляемая сумма, если у вас правильные индексы и обновленная статистика.

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

Answer 2

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

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

Answer 3

Нормализовать - потому что это правильный логический дизайн - и затем использовать горизонтальное разбиение , если / когда необходимо отделить физический дизайн от логического.

Answer 4

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

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

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

• Каждая таблица должна содержать информацию по одному предмету. Когда каждый Таблица содержит факты только по одному предмету, вы можете сохранить информация о каждом предмете независимо от других предметов (Например, вы будете хранить адреса клиентов в другой таблице от заказы клиентов, так что вы можете удалить один заказ и еще вести информацию о клиенте).

Answer 5

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

Если бы это были просто адреса разных типов без других объектов, я бы сохранилони в одной таблице.

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

Answer 6

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

Отель ---> Адрес

AirPort -> Адрес

и т. Д.

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

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

Посмотрите книгу Enric Envas и концепцию DDD:

http://lostechies.com/jimmybogard/2008/05/21/entities-value-objects-aggregates-and-roots/

Answer 7

Для 10 миллионов записей вам лучше поместить адреса в отдельную таблицу.

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

Адресная таблица

• address_id
• city_id - это избыточно, но ускоряет поиск
• street_id
• street_number (varchar, это может быть что-то вроде "32 / c 2nd floor 15")

Street table

• street_id
• city_id
• street_name

Таблица городов

• city_id
• city_name

И таблицы Person, Hotel, Office и т. Д. Будут иметь address_id

Answer 8

Лично я думаю, что адрес - это адрес, поэтому он должен быть в одной таблице. Любая дополнительная информация о том, какой это тип адреса, может храниться вместе со ссылками на владельца. Например, компания может иметь 5 адресов, а таблица CompanyAddress может иметь столбец IsHeadOffice вместе с CompanyId, AddressId и т. Д.