Блог

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

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

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

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

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

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

Вам также следует добавить ограничение внешнего ключа для uid к идентификатору в таблице users и ограничение внешнего ключа к nid для id в таблице уведомлений. Добавление ограничений внешнего ключа гарантирует, что вы не будете вставлять uid или nid, которые на самом деле не существуют, в вашу таблицу notifications_seen.

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

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