Дизайн реляционной базы данных - двойной первичный ключ в одной таблице?

0

У меня есть таблица, в которой хранятся оценки пользователей для элементов. Я хочу разрешить каждому пользователю оценивать элемент только один раз, есть ли способ заставить базу данных не допускать дублирование для itemId и userId?

Изображение 174551

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

itemId= 1 & userId = 1

следует разрешить:

itemId= 2 & userId = 1
itemId= 1 & userId = 2

не следует допускать:

itemId= 1 & userId = 1
  • 0
    Я с подозрением помещаю эту логику в базу данных. Похоже, он должен принадлежать к остальной части кода проверки.
Теги:
database-design
primary-key

3 ответа

3
Лучший ответ

Да. Создайте первичный ключ как для itemId, так и для userId.

Чтобы сделать это в T-SQL (SQL Server), вы должны использовать что-то вроде:

CREATE TABLE rating (
  itemId int NOT NULL
    CONSTRAINT fk_rating_item FOREIGN KEY REFERENCES item ( itemId ),
  userId int NOT NULL
    CONSTRAINT fk_rating_user FOREIGN KEY REFERENCES [user] ( userId ),
  thumbsUp int,
  thumbsDown int,
  CONSTRAINT pk_rating PRIMARY KEY ( itemId, userId )
)

(Предполагается, что ваша таблица элементов - это "элемент", а ваша таблица пользователей - "пользователь".)

Я не уверен, почему у вас есть значение как для больших, так и для больших пальцев? Если это логическое значение, вам может понадобиться только одно: если большие пальцы - это 0, тогда это все равно будет падать.

Изменить: определение составных клавиш

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

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

Поделиться
  • 2
    Недостатком использования составных первичных ключей является то, что при наличии связей с другими таблицами вам может понадобиться и составной внешний ключ. Это может не быть фактором в этом примере, но это может быть сложным в других. Скажите, если у каждого рейтинга есть много параграфов и много вложений, у каждого из которых есть своя таблица. Тогда для этих таблиц также потребуются столбцы itemId и userId, и вам нужно быть осторожным, чтобы использовать оба ключа в обновлениях и запросах. В качестве альтернативы, вы можете иметь один суррогатный ключ для таблицы рейтингов и принудительно использовать itemId, уникальность userId с ограничением.
  • 0
    Алекс, то, что ты говоришь, правда. Однако, если вы анализируете предмет в сущности и отношения, и связываете все атрибуты с этой структурой ER, а затем довольно просто связываете атрибуты в отношения, вы в конечном итоге получите таблицы, в которых никогда не будет сущностей, ссылающихся на отношения или отношения. ссылаясь на другие отношения. По крайней мере, не сначала.
0

Большинство баз данных позволят использовать составные первичные ключи из нескольких столбцов. Какую базу данных вы используете?

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

Пример типа mySQL:

createuserratings.sql
CREATE TABLE USERRATINGS
( 
    itemId     INT NOT NULL,
    userId     INT NOT NULL,
    thumbsUp   INT NOT NULL,
    thumbsDown INT NOT NULL,
    PRIMARY KEY (itemID, userID)
);

Выполняйте поиск составных/составных первичных ключей в документации mySQL, и вы должны получить много информации (я не использую mySQL).

Поделиться
  • 0
    я использую mysql
0

Использовать составной первичный ключ (первичный ключ, состоящий из 2 столбцов).

CREATE TABLE Rating 
(
 itemID     INT NOT NULL
,userID     INT NOT NULL
,thumbsUP   INT NOT NULL
,thumbsDown INT NOT NULL
,PRIMARY KEY (itemID, userID)
);
Поделиться
  • 0
    спасибо, так что бы я сделал по-другому, если бы не хотел иметь составной первичный ключ?
  • 1
    Я бы сказал, что ты не сделал бы ничего по-другому. Рейтинг является соединительной таблицей и в этом контексте является единственным способом установить связь между таблицей пользователя и таблицей элементов.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню