Блог

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

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

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

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

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

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

С уважением,

Shardul

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

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

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

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

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

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

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

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

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

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

Таблица улиц

• street_id
• city_id
• имя_стрита

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

• city_id
• имя_города

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

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

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

Аэропорт —> Адрес

и т. д

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

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

Взгляните на книгу Энрика Энваса и концепцию DDD:

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

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

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

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

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

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

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

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

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