Base de données Conception: Alternate aux clés composites?

Question

Je suis la construction d'un système de base de données et ayant des problèmes avec la conception d'un de mes tableaux.

Dans ce système, il y a une table d'utilisateurs, une table d'objet, une table d'éléments et le tableau des coûts.

Un enregistrement unique dans le tableau des coûts est de déterminer par l'utilisateur, l'objet, l'article et l'année. Cependant, il peut y avoir plusieurs enregistrements qui ont la même année si l'article est différent.

La hiérarchie va user-> object-> item-> année, plusieurs années uniques par article, plusieurs éléments uniques par objet, plusieurs objets uniques par utilisateur, plusieurs utilisateurs uniques.

Quelle serait la meilleure façon de concevoir le tableau des coûts?

Je pense y compris le userid, objectid et Itemid comme clés étrangères, puis en utilisant une clé composite constitué de userid, objecid, itemid et costyear. J'ai entendu dire que les clés composites sont une mauvaise conception, mais je ne suis pas sûr comment structurer ce pour échapper à l'aide d'une clé composite. Comme vous pouvez le dire à ma base de données des compétences de construction sont un peu rouillés.

Merci!

P.S. S'il importe, c'est un ınterbase db.

Answer 1

Pour éviter la clé composite, vous définissez simplement une clé de substitution. Cela est une valeur artificielle, par exemple un compteur automatique.

Vous pouvez toujours (et devrait) définir une contrainte unique sur ces colonnes.

BTW: son non seulement recommandé de ne pas utiliser des clés composites, il est également recommandé d'utiliser des clés de substitution. Dans toutes vos tables.

Answer 2

Utilisez un champ de clé généré en interne (appelée clés de substitution), quelque chose comme CostID, que les utilisateurs ne verront jamais, mais identifiera de manière unique chaque entrée dans le tableau des coûts (dans SqlServer, des domaines tels que uniqueidentifier ou IDENTITÉ ferait l'affaire.)

Answer 3

Essayez de construire votre base de données avec une clé composite en utilisant exactement les colonnes que vous avez décrites, et de voir ce qui se passe. Vous pourriez être agréablement surpris. Faire en sorte qu'il n'y a pas de données manquantes dans ces quatre colonnes, et faire en sorte que deux lignes ont la même valeur dans les quatre colonnes contribuera à protéger l'intégrité de vos données.

Lorsque vous déclarez une clé primaire composite, l'ordre des colonnes dans votre déclaration n'affectera pas les conséquences logiques de la Dclaration. Cependant, l'indice composite que le SGBD construit pour vous aurez également les colonnes du même ordre, et l'ordre des colonnes dans un indice composite a une incidence sur la performance.

Pour les requêtes qui spécifient une seule, deux ou trois de ces colonnes, l'indice sera inutile si la première colonne de l'index est une colonne non spécifiée dans la requête. Si vous savez à l'avance comment vos requêtes sont gonig pour moi, et qui interroge le plus besoin de courir vite, cela peut vous aider à déclarer les colonnes de la clé primaire dans le bon ordre. Dans de rares circonstances créant deux ou trois indices supplémentaires d'une colonne peut accélérer certaines requêtes, au prix de ralentissement des mises à jour.