SQL - Как отслеживать «простые отношения»

Question

Я надеюсь, что кто -то сможет отредактировать мое название, чтобы лучше описать, что я имею в виду, потому что я не знаю точно, как это будет вызвано. Тем не менее, рассмотрим эту настройку: я хочу создать систему уведомлений, где пользователю отображается сообщение, пока он не нажмет «Увольнение». Затем мне нужно «помнить», что этот пользователь отклонил уведомление, поэтому я больше не показываю его ему. Вот мое текущее решение

• users Таблица имеет uid Первичный ключ и информация пользователя
• notifications Таблица имеет nid Первичный ключ и текст уведомления
• notifications_seen Таблица с двумя столбцами, uid а также nid

Когда кто -то нажимает увольнение по уведомлению, я храню их uid и уведомление nid в notifications_seen. Анкет Кажется, это работает нормально, но у PhpmyAdmin есть гигантские красные сообщения, в которых говорится, что notifications_seen нет индекса. Однако ни один столбец не уникален. Если у меня действительно будет очень совершенно бесполезная колонка в notifications_seen И назовите это основным ключом? Есть лучший способ сделать это?

Answer 1

Вы можете использовать более одного столбца, чтобы создать свой основной ключ. В этом случае вы должны установить NID и UID в качестве основного ключа в вашей таблице уведомлений_seen. Идея здесь заключается в том, что, хотя ни nid, ни UID не будут уникальными в вашей таблице уведомлений_seen; Пара NID/UID уникальна. Вы должны добавить ограничение первичного ключа в эти два столбца. Обычно это то, что вы хотели бы сделать для такой ситуации.

Есть моменты, когда вы можете действительно захотеть создать строку автоматического приема, чтобы упростить первичный ключ. Например, когда ваш лучший ключ кандидата состоит из множества столбцов (я вытаскиваю это из воздуха; но, скажем, 4 или более столбцов) или у вас есть столбцы, которые содержат строки; Что было бы медленнее, чтобы соответствовать при поиске. Но для этой ситуации просто добавление ограничения первичного ключа к двум столбцам должно быть более чем хорошо.

Первичные ключи индексируются по умолчанию; Вот почему вы должны просто добавить ограничение первичного ключа в два столбца. Это также сохранит целостность ваших данных, убедившись, что вы не случайно вставляли строки с той же парой UID/NID.

Вы также должны добавить ограничение иностранного ключа на UID в идентификатор в таблице пользователей, а также ограничение иностранного ключа в NID на идентификаторе в таблице уведомлений. Добавление ограничений иностранного ключа гарантирует, что вы не вставляете UIDS или NIDS, которые на самом деле не существуют в вашей таблице уведомлений.

Answer 2

Вы можете создать составной первичный ключ (состоящий из обоих uid а также nid).

Answer 3

Вы можете сделать индекс на notifications_seen который содержит оба Колонны! Или создайте отдельный столбец только для первичного ключа или оба - имея индекс на uid а также nid мощь Ускоряйте запросы (но не беспокойтесь об этом, пока не начнете замечать серьезные проблемы с производительностью - просто помните об этом на будущее). Наличие первичного ключа для этих отношений с n: n не ужасная вещь.