УНИКАЛЬНОЕ Ограничение на Комбинацию двух значений столбца

Question

УНИКАЛЬНОЕ Ограничение на Комбинацию двух значений столбца

0

Не был уверен, как сформулировать вопрос так плохо, если это звучит странно.

У меня есть таблица в моей базе данных под названием friendRequests со следующими столбцами: id, sender_id, recipient_id и status. Как я могу убедиться, что никакая другая строка не дублирует значения recipient_id и sender_id?

Например, если у меня была строка в таблице со следующими значениями: (1, 4, 6, 0), как я могу убедиться, что никакая другая строка не имеет sender_id из 4 и recipient_id из 6 И что никакой другой строка имеет sender_id из 6 и recipient_id из 4?

Natividad Alvarez 17 янв. 2018, в 20:16

Источник

Теги:

mysql

node.js

3 ответа

0

Я слышу, что если пользователь A приглашает пользователя B, вы не хотите создавать новую запись для пользователя B, предлагающего использовать A.

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

Evert 17 янв. 2018, в 16:44

0

Итак, мне нужно просто выполнить проверку запроса, если запрос о дружбе уже существует между обоими пользователями, и создать его, если его нет? Это действительно лучший способ сделать это?
Natividad Alvarez 17 янв. 2018, в 18:53
0

@NatividadAlvarez Я думаю, что предложение от dognose использовать отдельное поле (поля) может быть хорошей альтернативой.
Evert 17 янв. 2018, в 20:45
0

Лично я считаю, что было бы лучше обрабатывать дублирующиеся записи с помощью SQL, потому что подобные вложенные запросы, особенно когда они являются функциями обратного вызова, могут сделать мой код более подверженным ошибкам и излишне сложным. Вот почему я просил решение SQL.
Natividad Alvarez 17 янв. 2018, в 22:33

Показать ещё 1 комментарий

0

Вы должны создать уникальный индекс в таблице.

create unique index sender_recipient
on friendRequest (sender_id, récipient_id)

Lorenz Meyer 17 янв. 2018, в 15:31

Ещё вопросы

Итак, мне нужно просто выполнить проверку запроса, если запрос о дружбе уже существует между обоими пользователями, и создать его, если его нет? Это действительно лучший способ сделать это?
@NatividadAlvarez Я думаю, что предложение от dognose использовать отдельное поле (поля) может быть хорошей альтернативой.
Лично я считаю, что было бы лучше обрабатывать дублирующиеся записи с помощью SQL, потому что подобные вложенные запросы, особенно когда они являются функциями обратного вызова, могут сделать мой код более подверженным ошибкам и излишне сложным. Вот почему я просил решение SQL.

dognose · Accepted Answer · 2018-01-17T18-13-00.000Z

0

Лучший ответ

Для тех same relations - используйте уникальное ограничение для <sender, receiver>.

Обратное отношение <receiver, sender> однако, будет возможно, вызывая его разные идентификаторы для единственного ограничения ключа.

Чтобы справиться с этим (используя ограничение ключа uniqe), вам нужно добавить еще один столбец, позвольте ему называть его friendship Там вы добавите уникальное ограничение ключа и вставьте идентификаторы пользователей, объединенные, НО ЗАКАЖИ:

Т.е. если пользователь 3 отправляет запрос друга на 10, вы введете 3-10 в этот столбец. Если приглашение будет от 10 до 3, вы также добавите 3-10.

Таким образом, вы можете отслеживать, что ВОЗ инициировала дружбу (sender_column=3, receiver-column=10), но также гарантирует, что нет обратного приглашения (friendship=3-10 уже существует)

Так что что-то вроде

INSERT INTO friendships(sender, receiver, friendship) VALUES(3,10,"3-10");
or vice versa:
INSERT INTO friendships(sender, receiver, friendship) VALUES(10,3,"3-10");

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

dognose 17 янв. 2018, в 18:13

0

Я бы сказал, что хуже всего использовать строковое поле и просто создать еще два столбца с уникальным ограничением для них обоих.
Evert 17 янв. 2018, в 20:44
0

Я на самом деле думал о том, чтобы сделать что-то вроде второго ограничения, но не был точно уверен, как это будет работать / как его реализовать. Спасибо за объяснение.
Natividad Alvarez 17 янв. 2018, в 22:16
0

@Evert Это совсем не поможет, так как возможен другой набор «обратных отношений». Т.е. с 4 столбцами вы можете вставить 1|2|2|1 а также 2|1|1|2 . Вам НУЖНА комбинация ОБОИХ уникальных идентификаторов, отраженных в ОДНОМ столбце, чтобы покрыть это, потому что каждая «пара» столбцов может иметь обратную вставку, которая не охватывается ограничением уникальной пары.
dognose 17 янв. 2018, в 22:31
0

@Evert Независимо от «подсчета» уникальных пар столбцов: Предположим , 5 пар, так что 10 столбцов - имеется ровно одна комбинация отражает обратную вставку не подпадают под ограничения (ы): 1010101010 против 0101010101 .
dognose 17 янв. 2018, в 22:52
0

@ Dognose Я бы предложил отсортировать идентификаторы, чтобы при наличии 2 столбцов первый столбец всегда имел наименьшее число. Вы все еще должны сделать это в своем предложении, так почему бы не сделать это в 2 колонках.
Evert 17 янв. 2018, в 22:54
0

Нет, я бы предложил добавить 2 дополнительных столбца вместо 1 дополнительного столбца, который всегда сортируется. 2 дополнительных столбца, в которых используется правильный тип столбца, лучше, чем тип столбца VARCHAR в вашем предложении.
Evert 17 янв. 2018, в 22:56
0

@Evert Можете ли вы выделить какие-либо "Проблемы" с колонкой varchar для идентификации определенной строки?
dognose 17 янв. 2018, в 22:58
0

@ Сделайте это в двух столбцах (lower_id, большее_ид), чтобы отбросить информацию, которая «запросила» дружбу.
dognose 17 янв. 2018, в 23:13
0

@ узнай, попробую это объяснение. Вы предлагаете 3 столбца (int, int, varchar), я предлагаю 4 (int, int, int, int). Лучше?
Evert 17 янв. 2018, в 23:43
0

Что касается того, почему VARCHAR хуже ... вы должны быть в состоянии ответить на этот вопрос самостоятельно. Почему бы не использовать VARCHAR для каждого поля в базе данных?
Evert 17 янв. 2018, в 23:43
0

@Evert Дайте мне знать, как ваш (int, int, int, int) подход оказался. Как я уже говорил, это не поможет, так как возможен другой набор «обратных отношений». Т.е. с 4 столбцами вы можете вставить 1 | 2 | 2 | 1, а также 2 | 1 | 1 | 2. Вам НУЖНА комбинация ОБОИХ уникальных идентификаторов, отраженных в ОДНОМ столбце, чтобы покрыть это, потому что каждая «пара» столбцов может иметь обратную вставку, которая не охватывается ограничением уникальной пары ... Если int (для ключа) всегда лучше, чем varchar - тогда почему mysql разрешает varchar-primary.keys ?
dognose 21 янв. 2018, в 15:13
0

@Evert int -keys, как правило, работают быстрее, но это не значит, что вы можете решить все без исключения, используя int -key.
dognose 21 янв. 2018, в 15:18
0

@ Dognose, только что проверил. Работало отлично =). Причина, по которой первичные ключи varchar существуют, заключается в том, что не все является числом.
Evert 21 янв. 2018, в 21:59
0

И так, чтобы нам было ясно. Мое предложение использовать 2 ints работает, потому что я также предлагаю, чтобы для 2 ints они также были заказаны, как ваше собственное предложение с varchar. Конечный результат такой же, но лучше.
Evert 21 янв. 2018, в 22:01
0

@Evert ok, имея 4 Ints, первая пара, показывающая «направление приглашения», и вторая пара, показывающая «отношение» (упорядоченная вставка), тоже будут работать, верно. Из коробки не могу сказать, будет ли это быстрее, чем конкатенационные строки - но угадайте для чего-то меньшего, чем 20 миллионов записей, это на самом деле не имеет значения.
dognose 30 янв. 2018, в 21:25
0

Спасибо за подтверждение. Возможно, вы правы, но обычно рекомендуется использовать правильный тип столбца, если можете. Тем не менее, с небольшими базами данных вы, вероятно, также можете сделать буквально каждое поле VARCHAR.
Evert 30 янв. 2018, в 21:28
0

Я больше думал об этом и понял, что это может быть короче. Вы можете сделать это с 3-х дюймов. 2 для «отношения» и просто используйте 1 для «направления приглашения». Второй в направлении приглашения может быть выведен, потому что он отсутствует.
Evert 30 янв. 2018, в 21:29
0

@Evert Allways признает «лучшие» решения, поэтому SO - это не соревнование (по крайней мере, для меня). «3 int solution» также будет работать, если вы перенесете еще одну проверку в «code-part»: то есть if (3, 10,3) существует, (10,3,10) также не допускается. Однако, поскольку сортировка ТАКЖЕ происходит до вставки, она также сработает и, возможно, будет наиболее эффективным решением, когда дело доходит до запроса данных. немного больше усилий при вставке, но это не должно случаться так часто.
dognose 30 янв. 2018, в 21:37

Показать ещё 16 комментариев