Какова правильная таблица и структура соединения для связи «многие ко многим» между одними и теми же атрибутами одной и той же таблицы? - PullRequest
0 голосов
/ 12 сентября 2010

Допустим, у меня есть таблица Users со столбцом UserID, и мне нужно смоделировать сценарий, в котором пользователь может иметь несколько отношений с другим пользователем, например, телефонные звонки. Любой пользователь может инициировать 0 ... n телефонных звонков с другим пользователем.

Будет ли это классический соединительный стол вроде:

UserCalls
-----------------------
| CallerID | CalleeID |
-----------------------

Ответы [ 3 ]

3 голосов
/ 12 сентября 2010

Звучит так, будто вы на правильном пути ...

CREATE TABLE CallHistory
(
    CallerID   int,
    RecipientID   int,
    DurationInMinutes int,
    /*  etc  etc  */
    CallStartedAt    smalldatetime
)

Для вашего ПК, рассмотрите эту статью о выборе ПК: http://www.agiledata.org/essays/keys.html

3 голосов
/ 12 сентября 2010

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

Кроме того, с точки зрения бизнес-правил, если отношения обратимы, когда в любое время вы ищете звонки, вам нужно только, чтобы две стороны были одинаковыми (а не кто звонил кому), если таблица различает их в способ у вас может быть проблематичным. Типичным способом решения этой проблемы является наличие таблицы Calls и таблицы CallParties, которая связывает вызов со сторонами в вызове (которые могут иметь флаги, которые помогают идентифицировать инициатора вызова). Таким образом, зависимость порядка столбцов исчезает, и МОЖЕТ упростить некоторые запросы (это может усложнить другие). Это также может уменьшить количество необходимых индексов.

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

0 голосов
/ 12 сентября 2010

Да, это правильно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...