Есть ли случаи, когда соединительные таблицы добавляют больше сложности, чем необходимо? - PullRequest
1 голос
/ 06 ноября 2019

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

Кроме того, направления могут быть ManyToMany с шагами, а ингредиенты могут быть ManyToMany с количествами, а суммы могут быть ManyToMany с измерениями.

Есть лиСоглашение о том, когда и когда имеет смысл использовать соединительную таблицу?

1 Ответ

1 голос
/ 06 ноября 2019

Да, соглашение называется нормализация базы данных .

Каждое отношение «многие ко многим» требует своей собственной таблицы соединений, если вы хотите, чтобы ваша база данных находилась в нормальной форме.

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

Если вас не устраивает уровень сложности, который он представляет, не вините таблицы! Сложность возникает из-за реальной информации, которую вы пытаетесь смоделировать.

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

  • Сколько / какие рецепты имеют один и тот же тег?
  • Какое среднее количество тегов в рецепте?
  • Обновите все рецепты, чтобы изменить написание данного тега, или удалите данный тег из всех рецептов, в которых он есть.

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

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

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

...