Guide d'utilisation des clés composites pour identifier les lignes

Est-ce une bonne pratique (ou cela aurait-il des effets négatifs) d'utiliser un ensemble de 4 colonnes pour identifier une ligne comme étant unique (l'une étant une clé foriegn, les trois autres étant des types de données float)? J'essaie de construire une table qui (avec 4 clés liées) décrirait une entrée unique dans la table. Je suis curieux de savoir s'il s'agit d'un bon plan d'attaque ou s'il existe une meilleure solution.

À des fins visuelles, imaginez le tableau suivant. Nous avons des éléments d'inventaire qui sont organisés comme le tableau suivant: ( [K]est symbolique de la clé primaire, les lignes sont des relations)

    Sheet_Class        Sheet_Type         Sheet_Size
    ===========        ==========         ==========
[K] Sheet_Class-.  [K] Sheet_Type--.  [K] Sheet_Size
                 '---- Sheet_Class  '---- Sheet_Type
                                          Length
                                          Width
                                          Thickness

Les données peuvent se présenter de la manière suivante, mais par souci de concision, j'ai exclu de faire passer les colonnes liées:

 Sheet_Class    Sheet_Type    Sheet_Size                        (Tables)
[Sheet_Class]  [Sheet_Type]  [Length], [Width], [Thickness]     (Column Values)
=============  ============  ==============================

Aluminum
               5052-H32
                             48, 96, 0.032
                             48, 96, 0.040
                             48, 96, 0.063

               6061-T6
                             60, 120,0.032
                             60, 120,0.040
                             60, 120,0.063

Steel
               1018-CRS
                             48, 96, 0.018
                             48, 96, 0.023
                             48, 96, 0.031

En l'état (et comme je l'ai montré dans mon "schéma" ci-dessus), j'utilise une clé primaire entière simple (auto-incrémentée) pour les entrées de la table Sheet_Size . Cependant, j'aimerais savoir s'il est préférable d'utiliser une combinaison des colonnes Sheet_Type , Longueur , Largeur et Épaisseur à la place? Étant donné que chaque entrée dans Sheet_Size devrait partager toutes ces qualités uniques, et qu'un champ d'auto-incrémentation ne le démontrerait pas assez bien, est-ce la meilleure voie à suivre?

Si je n'explique pas assez bien la situation, faites-le moi savoir. Je me retrouve à avoir besoin de décomposer ces portions (classe vs type vs tailles de stock réelles) d'un matériel inventorié à d'autres fins logiques, mais je suis prêt à tout autre type de rétroaction.

Tout conseil serait apprécié.

Mise à jour (08-12-2011)

Après les réponses affichées, j'ai décidé de faire une combinaison de la réponse de Mark & la réponse de X-Zero . J'ai décidé que c'était une bonne idée de placer une contrainte unique sur les colonnes de longueur, largeur et épaisseur, mais j'aime aussi l'idée de décomposer les tailles de matériaux en lignes uniques et de les lier à une relation.

Malheureusement, je ne peux pas accepter les deux réponses, donc je vais accepter X-Zeros pour avoir (ce que je ressens) un regard plus critique sur le problème et offrir un ajustement du schéma.

Merci à tous pour vos réponses.

Après y avoir réfléchi, je réviserais légèrement la structure de votre table.
Tout d'abord, révisez votre tableau de taille de feuille:

Sheet_size
===========
Id
Length
Width
Thickness

Deuxièmement, créez une table de relation taille / type de feuille:

Sheet_size_type
================
Sheet_Type_Id
Sheet_Size_Id

Créez ensuite les contraintes suivantes:

1. La clé primaire (et l'index) de Sheet_sizedoit être la colonne id
2. Il devrait y avoir une sorte de clé (et d'index) unique appliquée aux dimensions dans Sheet_size. Considérez, deux feuilles de dimensions (48, 96, 0,5) et (96, 48, 0,5) sont-elles égales (c'est-à-dire, la direction des dimensions est-elle importante)? Ce type de problème peut être difficile à appliquer si vous utilisez les colonnes dans le cadre de la clé primaire, mais devient plus gérable lorsque vous utilisez des contraintes et des procédures stockées.
3. La clé primaire (et l'index) de Sheet_size_typedoit utiliser les deux clés étrangères, en commençant par celle avec la cardinalité la plus basse (probablement sheet_type, selon votre exemple). Vous voudrez peut-être un index supplémentaire dans l'autre sens, mais il peut ne pas être nécessaire.

Cette révision vous permettra d'économiser de l'espace dans la base de données (en proportion du nombre de types de feuilles utilisant la même taille) et ne devrait pas trop affecter les frais généraux.

Il existe d'autres problèmes potentiels concernant l'égalité / l'unicité si vous utilisez un floattype de données, car l'imprécision peut vous déclencher de manière inattendue. Vous devez déterminer si un type à virgule fixe, avec une précision donnée, serait plus approprié.

On dirait une décision clé naturelle vs substitut , une opinion sur laquelle va de réfléchi et pratique à académique , à la limite du dogme. Selon le SGBDR, il existe des considérations pour le modèle physique qui peuvent avoir des implications importantes sur les performances, par exemple le choix de la clé en cluster dans SQL Server.

Personnellement, si j'ai une clé candidate à attribut étroit et unique, je suis tenté de l'utiliser. Touches larges et / ou composites, par défaut j'ajoute un substitut au modèle. Dans votre cas, je voterais pour la colonne d'identité sur Sheet_Size en tant que clé principale en cluster et une contrainte unique sur le type / longueur / largeur / épaisseur.

Je vais vous rediriger un peu vers cette réponse d'une question précédente .

Citation: "En ce qui concerne la façon de concevoir cette clé primaire, il existe deux écoles de pensée:

• celle qui fait du PK une colonne distincte, généralement auto-générée, comme un GUID ou et incrémentation automatique INT (dans votre cas, une colonne unique unique d'identification);
• celui qui rend le PK en tant que colonne (ou ensemble de colonnes) interne à la table (dans votre cas, serait un nom d'utilisateur ou un e-mail ou SSN, tout ce qui rend cet utilisateur unique) qui identifie de manière unique un enregistrement.

À quelle ligne vous adhérez, ce n'est qu'une question de goût. "

Les effets secondaires de toute solution choisie pourraient être:

• L'utilisation de clés composées partout:

  • augmenter le stockage pour toutes les tables impliquées;
  • augmenter / compliquer les index sur les FK souvent utilisés;
  • complique un peu l'écriture de toutes vos déclarations de jointure
  • rendre M. Joe Celko heureux :-) (des références sur ses opinions concernant les clés naturelles ou artificielles peuvent être trouvées ici et ici , et surtout partout où il est interrogé sur la question)

• l'utilisation des clés générées:

  • simplifier les 3 étapes précédentes
  • compliquer la situation de réplication d'une table avec l'identité PK (références ici , ici ou ici )

Personnellement, je préfère les clés INT IDENTITY générées, mais ce qui vous convient devrait bien.

La clé composite est parfaitement logique. L'implémentation de cette clé garantit que les attributs métier ne peuvent pas être dupliqués. C'est une bonne chose car enregistrer plusieurs fois les mêmes données entraînerait une ambiguïté, des dépendances indésirables et rendrait plus probable les erreurs utilisateur et les données incorrectes.

La clé d'incrémentation automatique seule ne protégera pas l'intégrité de vos données d'entreprise. Si la clé d'incrémentation automatique ne sert aucun objectif particulier (par exemple en tant que cible d'une référence de clé étrangère dans une autre table), elle peut être supprimée en toute sécurité.