2008-12-14 13 views
1

J'ai un système de commentaire dans notre base de données. Tout comme stackoverflow -> chaque publication a une liste de commentaires. kewl.Ai-je besoin d'une contrainte de base de données spéciale sur cette table?

Les personnes anonymes peuvent aussi ajouter un commentaire ou des utilisateurs enregistrés.

Dans ma table, je pense avoir les éléments suivants:

  • Userid int NULLABLE
  • AnonymousNickname varchar (100) NULLABLE
  • AnonymousEmail varchar (200) NULLABLE

maintenant, cela ne peut être que l'un ou l'autre. Vous êtes enregistré ou non.

Donc, devrais-je appliquer un type de contrainte qui dit l'un ou l'autre .. et si oui, comment?

REMARQUE: la base de données est Microsoft SQL Server 2008.

acclamations!

Répondre

2

Une contrainte simple serait

(Userid is not null and AnonymousNickname is null and AnonymousEmail is null) 
or (Userid is null and AnonymousNickname is not null and AnonymousEmail is not null) 

Cela forcera seulement un ou l'autre à régler. Il semble que ce serait raisonnable en fonction de votre demande. C'est à vous de décider de l'appliquer dans la base de données ou dans votre application. Si c'est une contrainte difficile dont dépendent d'autres parties de votre application, alors je l'appliquerais probablement dans la base de données et la détecterais par la validation dans votre code.

+0

Je vais certainement vérifier cela dans l'application, mais j'aime toujours avoir un code vraiment serré _et_ un Db serré, donc je n'étais pas sûr si cela pourrait aussi être fait dans une base de données. Si c'est le cas, comment? –

+0

La réponse de tvanfosson EST comment vous le faites dans la DB - créer une contrainte sur la table et utiliser son code ... – RedFilter

+0

Oh .. désolé. Je pensais que c'était un code pseduo. Pardon. Je n'ai jamais fait de contrainte auparavant./moi cache. –

0

Je n'inclurais pas la contrainte. Vous devez renommer le champ de nom anonyme pour le nommer. Lorsqu'un utilisateur inscrit laisse un commentaire, placez son nom d'utilisateur dans le champ de nom. Cela vous évite d'effectuer une recherche dans la table des utilisateurs lorsque vous écrivez vos commentaires. En outre, si un utilisateur est supprimé de la table utilisateur, ses commentaires survivent à eux.

+0

votre approche dénormaliserait la base de données. Si un utilisateur est supprimé, il va avoir des tonnes de dossiers enfants et ne peut donc pas être littéralement supprimé, mais simplement marqué inactif de toute façon. – rmeador

+0

@ rmeador: mon schéma ou joemucchiello serait dénormaliser? Aussi, je ne comprends pas ce que vous essayez de dire, quand (si) un utilisateur est supprimé ?? –