SQL многие ко многим таблицам реализаций, но уникальные записи

Вот вам, ребята, хорошая подача из-под хэнда.

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

У меня есть таблица, в которой в качестве первичного ключа есть столбец идентификаторов, но два других столбца - это contentID и tagID. Что мне нужно сделать с таблицей, чтобы убедиться, что у меня есть одна и та же комбинация contentID и tagID только один раз.

sql

13.11.2008 01:51

ReactJs | Supabase | Добавление данных в базу данных

Это и есть ваш редактор таблиц в supabase.👇

Понимание Python и переход к SQL

Перед нами лабораторная работа по BloodOath:

1 332

Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

Вы устанавливаете уникальное ограничение на contentID, tagID.

Для SQL Server

ALTER TABLE ContentTag ADD CONSTRAINT
    IX_ContentID_TagID_Unique UNIQUE NONCLUSTERED ( contentID,  tagID ) 
GO

13.11.2008 01:53

Ответ принят как подходящий

С точки зрения моделирования данных нет причин, по которым вам нужен столбец идентификаторов в таблице сопоставления. Ограничение первичного ключа должно быть ограничением двух столбцов для contentID, tagID.

Некоторые фреймворки (например, Rails) требуют, чтобы таблица каждый имела суррогатный ключ с именем id, даже если это не имеет смысла для связи сущностей. Жалко, но очевидно, что это соглашение дает им некоторую эффективность в другом месте.

Вы всегда можете создать ограничение UNIQUE для contentID, tagID в дополнение к первичному ключу таблицы в столбце суррогатного ключа.

13.11.2008 02:05

Есть одна причина иметь числовой (суррогатный) ключ в таблице соединения многие-ко-многим ... То есть, когда есть другие дочерние производные таблицы, которым потребуются внешние ключи для возврата к записям в этой таблице ... т.е. , скажем, у вас есть Table PetStores с StoreId, таблица Breeds с BreedId и таблица соединения многие-ко-многим StoreBreeds, в которой есть строка для каждой комбинации store = Порода ... А затем предположим, что вы хотите отслеживать цену, и Скидка магазина для каждой породы в каждом магазине, поскольку она менялась с течением времени, поэтому вам нужна другая таблица для записи цены каждой породы в каждом магазине с действительными датами начала и окончания, отражающими диапазон дат, когда цена действовала для эта порода в этом магазине ..

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

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

13.11.2008 02:48

Рассмотрим эту проблему:

Таблица A имеет 2 дочерних таблицы (B и C)

PK B и C - это идентичность, и у них обоих есть FK обратно в Таблицу A.

У меня есть таблица D, которая является таблицей соединения на B и C

Таблица D имеет PK идентичности и FK обратно к B и C.

A ..... два ряда ... A1 и A2

B ... два ряда ... B1 (от FK до A1) и B2 (от FK до A2)

C ... две строки .... C1 (FK до A1) и C2 (FK до A2)

D ..... Я могу добавить следующее к D .... FK к B1 и FK к C1 ..... это неправильно.

Я хочу убедиться, что все, что B и C упоминаются в D, оба указывают на один и тот же A !!!

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