Les clés primaires et les clés étrangères constituent le ciment qui organise plusieurs tables en une base de données relationnelle efficace. La conception des clés primaires et des clés étrangères a un impact déterminant sur les performances et la disponibilité de la base de données physique.
Le schéma de la base de données doit être converti d'une conception logique théorique à une conception physique réelle. La structure des clés primaires et des clés étrangères est au cœur de ce processus de conception. Une fois la base de données conçue utilisée dans un environnement de production, il sera difficile de modifier ces clés, il est donc très nécessaire et intéressant de concevoir les clés primaires et étrangères pendant la phase de développement.
Clé primaire :
Les bases de données relationnelles s'appuient sur des clés primaires, la pierre angulaire du schéma physique de la base de données. Les clés primaires n’ont que deux objectifs au niveau physique :
1. Identifiez une ligne de manière unique.
2. En tant qu'objet pouvant être efficacement référencé par des clés étrangères.
Sur la base des deux utilisations ci-dessus, voici quelques principes que je suis lors de la conception de clés primaires au niveau physique :
1. La clé primaire ne doit avoir aucun sens pour l’utilisateur. Si un utilisateur voit des données dans une table de jointure qui représentent une relation plusieurs-à-plusieurs et se plaint qu'elles sont peu utiles, cela prouve que sa clé primaire est bien conçue.
2. La clé primaire doit être une seule colonne pour améliorer l'efficacité des opérations de jointure et de filtrage.
Remarque : Les personnes qui utilisent des clés composites s'excusent généralement pour deux raisons, toutes deux fausses. La première est que la clé primaire doit avoir une signification réelle. Cependant, donner une signification à la clé primaire ne facilite que la destruction artificielle de la base de données. La seconde est que vous pouvez utiliser cette méthode pour utiliser deux clés étrangères comme clés primaires dans une table de jointure qui décrit une relation plusieurs-à-plusieurs. Je suis également opposé à cette approche car : les clés primaires composites conduisent souvent à de mauvaises clés étrangères, c'est-à-dire que lors de la jointure de tables Devenez la table maître d'une autre table esclave et faites partie de la clé primaire de cette table selon la deuxième méthode ci-dessus. Cependant, cette table peut devenir la table maître d'autres tables esclaves et sa clé primaire. peut devenir la table maître d'autres tables esclaves. Dans le cadre de la clé primaire, si elle est transmise de cette manière, plus la table esclave est tardive, plus sa clé primaire contiendra de colonnes.
3. Ne mettez jamais à jour les clés primaires. En fait, puisque la clé primaire n’a d’autre but que d’identifier de manière unique une ligne, il n’y a aucune raison de la mettre à jour. Si la clé primaire doit être mise à jour, le principe selon lequel la clé primaire ne doit avoir aucune signification pour l'utilisateur est violé.
Remarque : Ce principe ne s'applique pas aux données qui doivent souvent être organisées lors de la conversion de données ou de la fusion de plusieurs bases de données.
4. La clé primaire ne doit pas contenir de données changeant dynamiquement, telles que l'horodatage, la colonne d'heure de création, la colonne d'heure de modification, etc.
5. La clé primaire doit être générée automatiquement par l'ordinateur. Si un humain intervient dans la création d'une clé primaire, cela aura un autre sens que celui d'identifier de manière unique une ligne. Une fois cette frontière franchie, il peut y avoir une incitation à modifier la clé primaire, de sorte que les moyens clés utilisés par ce système pour relier et gérer les lignes d'enregistrements tombent entre les mains de personnes qui ne comprennent pas la conception des bases de données.
Une clé étrangère est une contrainte d'intégrité au niveau de la base de données, qui est la méthode de mise en œuvre de la base de données « d'intégrité référentielle » mentionnée dans le livre de théorie de base des bases de données.
Bien entendu, l'attribut clé étrangère peut être supprimé Si vous ne souhaitez plus utiliser cette contrainte, cela n'aura certainement aucune incidence sur la programmation, mais lors de la saisie des données, le contrôle « intégrité référentielle » ne sera pas effectué sur les données saisies. .
Par exemple, il y a deux tables
A(a,b) : a est la clé primaire, b est la clé étrangère (de Bb)
B(b,c,d) : b est la clé primaire
Si je supprime l'attribut de clé étrangère du champ b, cela n'aura aucun impact sur la programmation.
Comme ci-dessus, b dans A est soit vide, soit une valeur qui existe dans b dans B. Lorsqu'il existe une clé étrangère, la base de données vérifiera automatiquement pour vous si b dans A existe dans b dans B.
1. L'expression externe exprime l'intégrité référentielle : celle-ci est inhérente aux données et n'a rien à voir avec le programme. Par conséquent, cela devrait être laissé au SGBD.
2. L'utilisation de bases de données externes est simple et intuitive, et peut être directement reflétée dans le modèle de données. Elle présente de grands avantages en termes de conception, de maintenance, etc., en particulier lors de l'analyse de bases de données existantes. Les avantages sont très évidents - je ne l'ai pas analysé. il y a longtemps, j'ai trouvé une base de données d'entreprise existante. Certaines des contraintes d'intégrité référentielle sont décrites par des clés étrangères, et certaines sont implémentées à l'aide de déclencheurs. Bien sûr, cela peut être dans le document, mais ce n'est peut-être pas complet, mais les clés étrangères sont très évidentes et intuitives.
3. Puisque nous pouvons utiliser des déclencheurs ou des programmes pour réaliser ce travail (en référence aux contraintes d'intégrité référentielle), le SGBD nous en a fourni les moyens, pourquoi devrions-nous le faire nous-mêmes ? Et il faut dire que ce que nous faisons n’est pas aussi bon qu’un SGBDR. En fait, les premiers SGBDR n'avaient pas de clés étrangères, mais maintenant ils en ont tous, je pense qu'il est logique que les fournisseurs de bases de données ajoutent cette fonctionnalité. De ce point de vue, les clés étrangères sont plus pratiques.
4. Concernant la commodité, sur la base des projets que j'ai dirigés, les programmeurs ont signalé qu'il était principalement difficile de saisir des données pendant le débogage : si les données peuvent violer l'intégrité référentielle, alors l'intégrité référentielle elle-même n'entre pas en conflit avec la réputation. le programme Trigger Futures ne doit pas être utilisé ; sinon, cela signifie que les données sont fausses et ne doivent pas du tout être saisies dans la base de données ! De plus, cela devrait également faire partie du système de test : le blocage des données illégales. En fait, le programme frontal devrait gérer cet échec de soumission. Les données appartiennent à l'entreprise et non au programme. Les programmes stockés doivent être séparés autant que possible des données, et vice versa.
Enfin, permettez-moi de parler de plusieurs principes de construction de clés :
1. Créez des clés étrangères pour les champs associés.
2. Toutes les clés doivent être uniques.
3. Évitez d'utiliser des clés composées.
4. Les clés étrangères sont toujours associées à des champs de clés uniques.
Cet article provient du blog CSDN Veuillez indiquer la source lors de la réimpression : http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx .