2011-08-02 3 views
0

Je suis confronté à une situation où j'ai besoin de référencer différents types de données. Mettez directement c'est un système de notification où les utilisateurs peuvent être informés des nouveaux commentaires sur une page Web qu'ils suivent ou des réponses aux commentaires qu'ils suivent.Question de base sur la modélisation SQL

Je donne les résultats suivants (réduite) Mise en page

Tableau: commentaires

comment_id (int) PRIMARY # primary key 
entry_id (int) NULL # id of the webpage (entry), null if reply to existing comment 
comment_parentid NULL # parent id of comment if reply, null if root comment 

Tableau: suiveurs

user_id (int) # the user following 
entry_id (int) NULL # webpage the user follows, null if it this entry is only for following replys to a specific comment 
comment_parentid NULL # comment the user follows replys to, null if the user if this following entry represents following of the complete post on the webpage (notification for all new comments) 

Comme vous le voyez, il n'a de sens que si exactement un des champs La question (entry_id, comment_parentid) est remplie.

J'ai également des problèmes pour trouver une clé primaire pour le tableau suivant. Parce que les clés primaires ne peuvent pas contenir de champs nullables.

Par conséquent, je pensais que je faisais juste un champ appelé "parent_id" ou "follow_item_id" et définissais un drapeau enum supplémentaire quel genre d'id parent il est.

Ainsi, le tableau suivant ressemblerait à ceci:

user_id (int) PRIMARY 
followed_item_id (int) PRIMARY 
followed_item_type ENUM('entry','comment') PRIMARY 

appliqué la même technique de modélisation de la table des commentaires ressemblerait à ceci:

comment_id (int) PRIMARY # primary key 
comnent_parentid_type ENUM('entry','comment') # parent id type. entry or comment. 
comment_parentid (int) # parent id representing comment or entry 

Mais je me souviens que j'ai eu un problème où je voulais faire quelque chose de similaire, mais il y avait de très bons arguments contre. Je ne peux pas me rappeler et ne peux pas trouver le poste.

Alors, quel est un bon moyen de structurer ce type de données?

Maby deux tables que je sélectionne toutes les deux avec une instruction UNION?

Répondre

0

L'argument contre la table "combo" est que vous ne pouvez pas avoir d'intégrité référentielle et vous devrez gérer vous-même les suppressions en cascade.

On dirait que faire deux tables fonctionnerait, par ex. suit_entries et follows_comments.

Bonne chance.