MySQL Database Design: один к одному, много ко многим, много к одному или слишком много?

Question

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

Мне трудно решить, какие типы отношений мне нужно установить.

У меня запланированы следующие основные таблицы.

products
-----
id
product_name
product_details
product_url
product_img
category_id
business_id


categories
-----
id
category_name
category_description
category_slug


businesses
----------------
id
business_name
business_phone
business_address
business_city
state_id
business_zip

state
-----
id
state_name

Когда я застреваю, решаю, какие типы отношений установить.

Каждый продукт может принадлежать только 1 категории ,и может принадлежать только 1 business

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

Я хочу иметь возможность получать продукты по категориям и город ,Например: «обувь» в «лос-анджелесе», или просто «обувь» или все товары в «лос-анджелесе»

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

Answer 1

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

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

Однако у меня есть следующие предложения:

Во-первых, всегда называйте свои таблицы в единственном числе, business не businesses.

Во-вторых, старайтесь избегать префикса таблицыname для имен столбцов, поэтому name, а не business_name - когда вы ссылаетесь на него в запросе, это все равно очевидно: business.name (дополнительные business_ в business.business_name избыточны)

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

business
----------------
id
name
phone
address
zip_code_id

zip_code
--------
id
city_id
name

city
----
id
state_id
name

state
-----
id
name

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

Answer 2

Вы должны взвесить преимущества и недостатки.

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

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

В заключение

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

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