2012-01-11 6 views
2

Je suis nouveau à la base de données de conception. Peut-être que c'est une question stupide, alors pardonnez-moi s'il vous plaît. Donc, la chose est que je conçois la base de données pour les utilisateurs. Une fois que l'utilisateur a rempli les informations d'enregistrement, il reçoit le numéro de reçu unique. Donc, ma question est depuis la réception non. est unique puis-je l'utiliser comme clé primaire dans le tableau Utilisateurs ou devrais-je m'en tenir à la méthode standard d'assignation d'ID utilisateur à chaque ligne de la table et utiliser ID utilisateur comme clé primaire?Confusion avec la clé primaire

+0

Quels sont ces reçus? – simchona

+2

L'utilisateur * est-il identifié * par son numéro de reçu? Comme dans: Gardera-t-il ce numéro jusqu'à la fin des temps et ce numéro ne sera-t-il jamais utilisé à d'autres fins que l'identification de cet utilisateur? Si oui, allez-y. Si non, utilisez un ID utilisateur distinct répondant à ces exigences. – Tomalak

+0

c'est comme lorsque l'utilisateur remplit l'info, le numéro de reçu unique est envoyé à l'email de l'utilisateur. et en utilisant ce numéro de reçu, il peut voir le statut de sa commande. – user1142462

Répondre

0

Si votre reçu pas. est compliqué assez - construit en utilisant des nombres et des caractères, ou 20 chiffres - mieux utiliser le UserId substitut

Si la réception ne peut être simple entier et peut être généré à partir de DB - une meilleure utilisation UserId et affecter sa valeur à ReceiptNo

Si ReceiptNo est simple entier et identifie l'utilisateur AND le seul utilisateur - l'utiliser comme PKey.

+0

Oleg Dog, merci pour la réponse rapide. Je pense qu'il est préférable d'utiliser des identifiants d'utilisateur auto-incrémentés puisque le numéro de reçu sera alphanumérique et de 8 caractères. – user1142462

1

si votre numéro de reçu ne contient que le numéro entier, alors, peut-être que vous pouvez faire de votre réception, aucun champ comme le numéro d'incrémentation automatique,

+0

Le numéro de reçu sera alphanumérique et pourra comporter 8 caractères. – user1142462

+0

Donc je pense que je devrais coller avec userID comme clé primaire droite? – user1142462

+0

oui, dans ce cas, – mack

2

Une table peut avoir plusieurs clés. Si le numéro de reçu est destiné à être unique et que vous voulez que le SGBD impose des dépendances clés sur cet attribut comme contrainte d'intégrité des données, alors oui vous devriez en faire une clé (avec unicité implémentée par une contrainte PRIMARY KEY ou UNIQUE fournit).

Désigner une clé comme étant «primaire» n'est pas particulièrement important - ou du moins, elle est aussi importante que vous le souhaitez. Ce qui compte vraiment, c'est l'ensemble des clés que vous choisissez. Les exigences pour toute clé sont l'unicité et l'irréductibilité. Les critères sensés pour choisir une clé sont également: Familiarité, simplicité et stabilité

+0

Et peut-être ajouter que typiquement, les substituts obtiennent un score très proche de zéro sur le critère de familiarité, et les non-substituts PEUVENT obtenir de mauvais résultats sur le critère de stabilité. –