Dois-je utiliser les clés primaires composites ou pas?
Il semble être la seule à être de 2e classe de soutien pour la base de données composite clés en Java de la JPA (via EmbeddedId ou IdClass annotations). Et quand j'ai lu sur des clés composites, indépendamment de la langue, les gens continuent à venir à travers comme étant une mauvaise chose. Mais je ne comprends pas pourquoi. Sont des clés composites est encore acceptable pour l'utilisation de ces jours? Si non, pourquoi pas?
J'ai trouvé une personne qui est d'accord avec moi:
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx
Mais un autre qui n'est pas le cas:
http://weblogs.java.net/blog/bleonard/archive/2006/11/using_composite.html
Est-ce juste moi, ou les gens sont pas capable de faire la distinction d'où une clé composite est appropriée ou pas? Je vois les clés primaires composites utile lorsque le tableau ne représente pas une entité à - dire lorsqu'elle représente une table de jointure.
Un exemple simple:
Actor { Id, Name, Email }
Movie { Id, Name, Year }
Character { Id, Name }
Role { Actor, Movie, Character }
Ici, l'Acteur, le Film et le Caractère évidemment l'avantage d'avoir une colonne d'Id comme clé primaire.
Mais le Rôle est un plusieurs-À-Plusieurs table de jointure. Je ne vois pas de point dans la création d'un id juste pour identifier une ligne dans la base de données. Pour moi, il semble évident que la clé primaire est { Actor, Movie, Character }. Il semble aussi que plutôt une fonction de limite, surtout si les données dans la table de jointure change tout le temps, vous pourriez vous retrouver avec une clé primaire collisions, une fois la clé primaire de la séquence s'enroule autour de 0.
Donc, revenons à la question initiale, est-il encore acceptable d'utiliser les clés primaires composites? Si non, pourquoi pas?
- Personnage { Id, Nom } -- c'est sûrement un argument en faveur de clés composites? Je veux dire, je ne vois pas comment la modélisation de Personnage séparément du Film dans lequel il apparaît a aucune valeur. Faire tous les caractères du nom de 'Robin des bois' utiliser le même ID? Et si le "Robin des bois" dans un Film n'est pas de l'homme-dans-Lincoln-vert-collants variété?
Vous devez vous connecter pour publier un commentaire.
Je pense qu'il n'y a pas de problème à l'aide d'une clé composite.
Pour moi la base de données c'est un composant sur son propre, qui doivent être traités de la même manière que nous traitons code : par exemple, nous voulons code propre, qui communique clairement ses intentions, qui ne fait qu'une chose et le fait bien, que ne pas ajouter inutiles niveau de complexité, etc.
Même chose avec la db, si le PK est composite, c'est la réalité, de sorte que le modèle doit être gardé propre et clair. Un composite PK c'est plus clair que le mélange auto-incrément + contrainte. Quand vous voyez une colonne ID qui ne fait rien, vous devez vous demander quel est le réel PK, existe-il d'autres choses cachées que vous devez être conscient, etc. Un clair PK ne pas laisser de doutes.
La base de données est la base de votre application, pour moi, nous avons besoin de la plupart des base solide que nous pouvons avoir. Sur cette base, nous allons construire l'application ( web ou non ). Donc je ne vois pas pourquoi nous devrions nous plier la db modèle pour se conformer à certaines spécifiques à un outil de développement/cadre/langue. Les données d'orienter la demande, et non l'inverse. Que faire si l'ORM changements dans l'avenir et devient obsolète et une meilleure solution semble qu'impose un autre modèle ? Nous ne pouvons pas jouer avec la db modèle pour s'adapter à cette ou ce cadre, le modèle doit rester le même, il ne doit pas dépendre de ce que l'outil que nous utilisons pour accéder aux données ...
Si le db changement de modèle dans l'avenir, il devrait changer à cause de la fonctionnalité ont changé. Si nous savons aujourd'hui comment cette fonctionnalité va changer, nous allons être à la modélisation de cette déjà. Et à l'avenir des modifications seront traitées lorsque vient le temps, nous ne pouvons pas prédire, par exemple l'impact sur les données existantes, de sorte que l'une colonne supplémentaire ne garantit pas qu'elle sera retenue à l'avenir des modifications ...
Nous devons la conception d'aujourd'hui, la fonctionnalité, et de garder la db modèle le plus simple possible, de cette façon, il sera facile de changer/évoluer dans le futur.
Dans mon opinion personnelle, vous devriez éviter les clés primaires composites pour plusieurs raisons:
Changements futurs: lors de la conception d'une base de données vous manquent parfois de ce que dans l'avenir va devenir important. Un exemple significatif pour ce qui est de la pensée d'une combinaison de deux ou plusieurs champs est unique (et donc peut devenir une clé primaire), alors que, dans l'avenir, vous souhaitez autoriser les valeurs Null ou d'autres non-valeurs uniques en eux. Avoir une seule clé primaire est une bonne solution solide contre de telles modifications.
Homogénéité: Si chaque table a un unique IDENTIFIANT numérique, et vous aussi de maintenir un certain standard, comme à son nom (par exemple, "ID" ou "tablename_id"), le code SQL de renvoi, c'est plus clair (à mon avis).
Il y a d'autres raisons, mais ce ne sont que quelques-uns.
La principale question que je voudrais poser est pourquoi ne pas utiliser une clé primaire si vous avez un ensemble de champs? Quel est le coût? Un entier supplémentaire index? Ce n'est pas trop mauvais.
Espère que ça aide.
Des questions similaires ont été posées sur de la SORTE, et il n'y a pas de consensus 😉
Si vous développez une application web, vous allez adorer seule colonne pk, comme ils font de votre Url plus simple.
Pour une séquence pour vous envelopper, vous auriez besoin de 2 milliards d'enregistrements dans une table unique (32 bits), ou 10^18 à 64 bits pk est.
Btw, votre modèle de données ne permet pas pour les personnages du film avec des acteurs inconnus.
Mon avis général est... non. ne pas utiliser les clés primaires composites.
Ils seront généralement compliquer Orm si vous les utilisez (Orm parfois aller jusqu'à demander les clés primaires composites "l'héritage de comportement") et en général, si vous utilisez plusieurs touches, une ou plusieurs d'entre eux ont tendance à être naturels plutôt que des techniques de clés, ce qui pour moi est le plus gros problème: à mon humble avis, vous devriez certainement faveur techniques de clés primaires.
Plus sur ce en Développement de base de données des Erreurs commises par AppDevelopers.
Les guerres de religions ont été et sont encore en cours sur ce sujet.
OO les gens ont ce zélé chose à propos de l ' "identité", et vous dire que la seule chose qui importe est la capacité de vous "identifier" "objets réels" à l'intérieur de vos programmes, et que composite, "la vraie vie" les clés ne vous causer des ennuis en essayant d'atteindre cet objectif.
Données les gens ont une chose à propos de l ' "unicité" qui est perçu comme "zélé" par l'OO côté, et de vous dire que la seule chose qui compte, c'est que si l'entreprise qui vous dit que la combinaison de valeurs pour l'attribut X et l'attribut Y doit être unique, alors il est de votre responsabilité de voir à ce que la base de données applique cette règle d'entreprise de l'unicité de l'combiné X+Y.
La façon dont vous voulez la réponse à votre question est juste une question de quelle religion vous préférez. Ma la religion personnelle de Données est un. Que la religion a prouvé être capable de survivre quelque hype et tendance depuis 1969.
C'est une chose religieuse. J'utilise des clés naturelles et à se détourner des mères porteuses. Je n'ai aucun problème avec les clés composites, soit en théorie ou en pratique.
Seulement le plus trivial du modèle logique impliquerait pas de clés composites. Appelez-moi paresseux, mais je vois pas besoin de compliquer le modèle de données en introduisant des mères porteuses dans le modèle physique sur la mise en œuvre. Bien sûr, je voudrais examiner un sur une table si les problèmes de performance ont été trouvés, mais j'ai la même approche que pour la dénormalisation c'est à dire comme un dernier recours. Habituellement à l'aide de substituts montants de l'optimisation prématurée, de l'OMI.
En Ruby pour les Rails, lorsqu'il n'est pas spécifier de manière explicite contraire, votre
Roletable serait un peu comme vous l'avez décrit (si les colonnes sont en fait les Id des autres tables). Encore, dans la base de données que vous pouvez faire en sorte de combinaisons uniques par la définition d'un index unique sur ces trois colonnes, si seulement à l'aide de la base de données optimisation de vos requêtes. Avec index unique en lieu et le cadre à l'aide de toute autre clé primaire de toute façon, il n'est pas nécessaire pour une supplémentaire numérique de la clé primaire dans votreRoletable. Cela dit, l'index unique pourrait pourrait très être définie comme une clé primaire composite à la place.Que pour les futurs changements: la définition d'une stricte base de données pour votre première itération sera d'éviter toute erreur de données persistantes, ce qui fera de migrations beaucoup plus facile.
Donc: je voudrais utiliser les clés primaires composites.
Je ne jamais les utiliser, dans les tables de jointure. Le seul moyen de garantir que chaque enregistrement de l'identifiant est unique et cohérente dans le temps est d'utiliser de façon synthétique les clés.
Clés composites semblent OK, en théorie, c'est pourquoi ils sont tentants, mais la pratique a montré que, généralement, ils indiquent qu'il y a une faille dans votre modèle de données. Pire encore, dans de nombreux cas, ils ne pourront pas garantir l'unicité, donné un assez grand ensemble de données. Et des ensembles de données toujours croître au fil du temps, de sorte que leur utilisation peut dire que vous avez planté une bombe dans votre application qui sera uniquement exploser lorsque l'application a été utilisée en production pendant un certain temps.
Je pense que les gens sont underplaying Orm. Chaque intégrer langage de programmation a un defacto ORM, et a eu pendant des années, car ils résoudre l'incompatibilité fondamentale entre OO et structures relationnelles. Essayer d'écrire un complexe, testable OO logiciel contre les bases de données SQL sans un ORM est très inefficace, au mieux.
Bonne Orm également fournir les pratiques et les outils qui le rendent beaucoup plus facile à créer et à maintenir la qualité constante de schéma de base de données, donc en moyenne, une équipe viendra à l'avance par la collaboration avec un ORM. Chez nous, l'artisanat schéma est un peu comme l'écriture de C++ ...des gens peuvent le faire, mais dans le monde réel, il est donc difficile de maintenir la qualité au fil du temps que la moyenne du produit n'est pas bon.
En termes de modèle de domaine, je ne vois rien de mal avec la création d'une clé primaire composite lorsque le tableau ne représente pas une entité à - dire lorsqu'elle représente une table de jointure (comme vous le mentionnez dans votre question), d'autres que si elle n'est pas montonically augmente, alors vous aurez un certain laps de page intermédiaires pendant les insertions.
Certains ORM de ne pas bien se débrouiller avec les clés primaires composites, il est peut-être plus sûr de créer un substitut de l'auto-entier pour la clé primaire, et de couvrir les colonnes avec un index non-cluster.
Je n'ai presque jamais vu un cas où une clé composite était une bonne idée (à l'exception, de rejoindre table composé de seulement deux clés de substitution). Dans le premier endroit que vous perdez de l'espace dans les tables enfants. Vous êtes nuire à la performance dans la rejoint, en tant qu'entier jointures sont généralement beaucoup plus rapide. Si vous avez la clé composite comme un index cluster (en parlant de SQL Server ici), vous sont à l'origine de la base de données pour être moins efficace pour stocker les documents et moins efficace dans la construction d'autres indices, qui utilisent tous le clusterd index.
Lorsque les données dans les principaux changements (Comme elle l'a presque inévitablement volonté), alors vous devez mettre à jour tous les tableaux connexes ainsi casuing massive élément de mises à jour et de gaspiller de la puissance de traitement sur une tâche qui est complètement inutiles lorsque la base de données est conçu pour utiliser surrogaste clés. Les clés primaires ne doivent pas seulement être unique, mais d'être immuable. Les clés composites ne parviennent souvent pas le deuxième test.
Si vous envisagez d'utiliser une technique qui nuit à la performance, qui provoque une mauvaise utilisation de la mémoire et de stockage de base de données, utilise de façon de plus d'espace dans les enregistrements enfants (un autre gaspillage de ressources) et exige une douloureuse mise à jour de ce qui peut être des millions d'enregistrements enfants lorsque les choses changent. Et qui peuvent faire qu'il est difficile d'utiliser un ORM? Pourquoi voudriez-vous faire cela? Parce que vous êtes trop paresseux pour mettre une clé de substitution, puis de définir un index unique sur le potentiel de clé composite? Est-il un gain à l'aide d'un indice composite? Pour le manque de 5 minutes de travail, vous êtes définitivement de nuire à votre base de données?