Каковы плюсы и минусы ассоциативного стола?

Question

В РСУБД, я полагаю, есть несколько способов создать связь между таблицами.Поэтому я хотел бы спросить, каковы плюсы и минусы между созданием отношения с ассоциативной таблицей и без ассоциативной таблицы .Есть ли формальное решение для решения обоих?

Используя общие таблицы, ниже я продемонстрирую, что я имею в виду:

Пример № 1 (без ассоциативной таблицы)

пользователи

+----+-------+
| id | name  |
+----+-------+
|  1 | John  |
|  2 | James |
|  3 | Jacob |
+----+-------+

комментарии

+----+-----------------------------+---------+
| id |            text             | user_id |
+----+-----------------------------+---------+
|  1 | Lorem ipsum dolor sit amet. |       1 |
|  2 | Praesent ultricies libero.  |       2 |
|  3 | Donec eget blandit nunc.    |       3 |
+----+-----------------------------+---------+

Примечание: ссылка на автора комментария хранится в comments.

Пример # 2(С ассоциативной таблицей)

пользователи

+----+-------+  
| id |  name |  
+----+-------+  
| 1  |  John |  
| 2  | James |  
| 3  | Jacob |  
+----+-------+  

комментарии

+----+-----------------------------+  
| id |                        text |  
+----+-----------------------------+  
| 1  | Lorem ipsum dolor sit amet. |  
| 2  |  Praesent ultricies libero. |  
| 3  |    Donec eget blandit nunc. |  
+----+-----------------------------+  

comment_user

+----+--------------+-----------+
| id | comment_id   | user_id   |
+----+--------------+-----------+
| 1  | 1            |        1  |
| 2  | 2            |        2  |
| 3  | 3            |        3  |  
+----+--------------+-----------+

Примечание: ссылка наАвтор комментария хранится в comment_user.

Answer 1

Ничего формального, нет.

Плюсы:

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

Минусы:

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

Кроме того, столбец id в таблице comment_user представляется бессмысленным.

Answer 2

Вы неправильно используете термин «сводная таблица».Существуют различные термины для промежуточной таблицы;общие имена включают соединительную таблицу и ассоциативную таблицу.Плюсы и минусы также странны - вы приглашаете мнение, которое явно не допускается при переполнении стека.Но ваш вопрос скорее ошибочен.Таким образом, он заслуживает ответа.

Ваши два варианта делают разные вещи.Первый реализует отношение 1: n.У данного пользователя может быть много комментариев.Но комментарий может принадлежать только одному пользователю.

Второй реализует отношение m: n.У данного пользователя может быть много комментариев.Данный комментарий также может иметь много пользователей.

Очевидно, что отношение 1: n может быть реализовано как особый случай отношения m: n.Однако это излишне и неэффективно.

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