Еще один вопрос отношения многих ко многим - PullRequest
Новая
       6

Еще один вопрос отношения многих ко многим

2 голосов
/ 03 сентября 2011

Моя база данных включает в себя таблицу «Клиенты» и «Подкатегории».
Клиенты могут принадлежать к одной или нескольким подкатегориям (и, конечно, в любой подкатегории есть один или несколько клиентов).
Интересно, какаяЛучшее решение для связи этих таблиц, которые имеют общие отношения «многие ко многим»:

  • Таблица «стандартной» точки соединения CustomerSubcategory, которая включает в себя только два поля: CustomerID (PK, FK) и SubcategoryID (PK,FK) или
  • Таблица CustomerSubcategoryDetail, которая также будет содержать поля CustomerSubcategoryDetailID (PK), а также поля SubcategoryID (PK, FK) и CustomerID (FK).

Есть совет?

Приветствия, Corbex

Ответы [ 3 ]

2 голосов
/ 03 сентября 2011

Я не думаю, что дополнительный PK в соединительной таблице добавляет какое-либо значение.Вам когда-нибудь придется искать значения в этой таблице без возможности идентифицировать их по Customer и / или SubCategoryID?Будет ли значение CustomerSubCategoryDetailID использоваться где-либо еще?

В моем блоге началось интересное обсуждение, когда я пожаловался на то, что люди толкают по колену столбец IDENTITY на каждую отдельную таблицу .Некоторые люди привели несколько хороших аргументов в пользу наличия столбца OrderDetailID в таблице OrderDetails.К вам относится какая-либо из этих ситуаций?

1 голос
/ 03 сентября 2011

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

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

1 голос
/ 03 сентября 2011

Я не вижу необходимости в третьем столбце с customerubcategoryid;поэтому я бы пошел с первым вариантом.Дополнительный столбец не даст вам никакого преимущества ни в одном из ваших объединений.Вы даже не будете его использовать.

...