дизайн и преимущества ассоциации «один ко многим» и «многие ко многим»

Question

У меня есть довольно простой вопрос, который смущает меня по какой-то странной причине.

У меня есть две таблицы, одна из которых является таблицей Pages, а другая - меню.Мне интересно, каковы преимущества использования другой таблицы для отображения?Ниже приведены две реализации, о которых я думаю:

Единственное отличие, которое я вижу, - это способ поиска.Например, в первой реализации:

a) если мне нужны все страницы определенного меню, я сделаю запрос на все page_ids определенного имени меню и соединю их с идентификатором таблицыСтраницы (именно поэтому я думаю, что эта реализация более медленная).

b) если мне нужны все меню определенной страницы, я буду искать все меню, которые имеют page_id конкретной страницы.

Во второй реализации более типичный и простой (и с большим количеством объединений).

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

Или есть какая-то другая конкретная причина?Являются ли эти два проекта идентичными с точки зрения того, что они могут выполнить, или есть какие-то другие ограничения в первом проекте, и я всегда должен выбирать второй?

Answer 1

Два варианта НЕ идентичны; последнее является правильным выбором для использования в дизайне «многие ко многим». Использование объединяющей таблицы означает, что у вас может быть много страниц (A, B, C) и много меню (1,2,3), и вы можете связать набор меню с набором страниц (получая A1, A2, A3, B1 , B2, B3, C1, C2, C3).

Первый дизайн предполагает, что с любым данным меню может быть связана только одна страница. Меню 1 может быть связано только с одной страницей (это будет A, B или C?). Чтобы связать одно и то же меню с несколькими страницами, вам нужно иметь одну строку в таблице меню для каждой связанной страницы.

Answer 2

Страница и меню имеют отношение многие ко многим. Вопрос в том, есть ли какая-либо информация об этих отношениях, которую нужно отслеживать, кроме простого факта отношений?

Если вы, например, публикуете журналы, у вас могут быть отношения с журналом <-> человека, которые были M2M - люди могли подписаться на несколько журналов, а журналы могли иметь несколько подписчиков. Но есть информация о пересечении журнала и человека, которого вы хотели бы отслеживать - дата начала, срок годности и т. Д. Использование таблицы пересечений дает вам место для их размещения.

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

Поэтому я всегда использую пересечения.

Answer 3

Ваша первая реализация - 1 для многих, а не для многих. Ваша вторая реализация - много-много с полезной нагрузкой (примечание: обычно ей не нужен идентификатор).

Много ко многим означает, что вы можете добавить n элементов, сопоставленных с n другими элементами. «1 ко многим» означает, что у вас есть только один элемент, сопоставленный с n элементами.

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