SQL - comment garder une trace des « relations simples »

Question

J'espère que quelqu'un peut modifier mon titre pour mieux décrire ce que je veux dire, parce que je ne sais pas exactement ce que cela serait appelé. Cependant, considérerais cette configuration: Je veux créer un système de notification, où un message est affiché à un utilisateur jusqu'à ce qu'il clique sur « rejeter ». J'ai alors besoin de « se souvenir » que cet utilisateur a rejeté la notification si je ne montre pas encore à lui. Voici ma solution actuelle

• table users a une uid clé primaire et les informations utilisateur
• table notifications a une clé primaire de nid et le texte de notification
• table notifications_seen avec deux colonnes, uid et nid

Lorsque quelqu'un clique sur une notification de rejeter, je stocker leur uid et de nid dans notifications_seen de la notification. Cela semble fonctionner très bien, mais phpMyAdmin a des messages rouges géants me disant que notifications_seen ne dispose pas d'un index. Cependant, ni la colonne est unique. Dois-je vraiment une colonne supplémentaire tout à fait inutile dans notifications_seen et appel qu'une clé primaire? Y at-il une meilleure façon de le faire?

Answer 1

Vous pouvez utiliser plusieurs colonnes pour créer votre clé primaire. Dans ce cas, vous devez régler ET JNV uid comme clé primaire dans votre table notifications_seen. L'idée ici est que même si ni JNV ou uid sera unique dans votre table notifications_seen; la paire de JNV / uid est unique. Vous devez ajouter une contrainte de clé primaire à ces deux colonnes. Ceci est généralement ce que vous voulez faire pour ce genre de situation.

Il y a des moments où vous voudrez peut-être en fait de créer une ligne d'auto-incrément pour simplifier la clé primaire. Par exemple, lorsque votre meilleur candidat clé se compose d'un grand nombre de colonnes (je tire ce de l'air, mais disons 4 ou plusieurs colonnes) ou si vous avez des colonnes qui contiennent des chaînes; ce qui serait plus lent à répondre lorsque vous faites des recherches. Mais cette situation, tout en ajoutant la contrainte de clé primaire aux deux colonnes devrait être plus que bien.

Les clés primaires sont indexées par défaut; ce qui est la raison pour laquelle vous devez simplement ajouter la contrainte de clé primaire aux deux colonnes. Cela permettra également de préserver l'intégrité de vos données en vous assurant de ne pas accidentellement insérer des lignes avec la même paire de uid / JNV.

Vous devez également ajouter une contrainte de clé étrangère sur le uid à l'ID dans la table des utilisateurs, et une contrainte de clé étrangère à l'JNV sur l'id de la table des notifications. L'ajout des clés étrangères vous assurer de ne pas insérer ou uids JNV qui n'existent réellement dans votre table notifications_seen.

Answer 2

Vous pouvez être en mesure de créer une clé primaire composé (comprenant à la fois uid et nid).

Answer 3

Vous pouvez faire un index sur notifications_seen qui contient les deux colonnes ! Ou créer une colonne séparée juste pour une clé primaire, ou les deux - ayant un indice sur uid et nid peut accélérer les requêtes (mais ne vous inquiétez pas trop à ce sujet jusqu'à ce que vous commencez à remarquer la performance majeure problèmes - rappelez-vous juste pour l'avenir). Avoir une clé primaire pour ces n. N relations n'est pas une chose terrible