Nous concevons une base de données dans laquelle j'ai besoin de considérer certains FK (clé étrangère) contraintes. Mais il n'est pas limité à structuration formelle et normalisation. Nous allons pour cela seulement s'il fournit prestations de performance ou d'évolutivité.
Je vais avoir traversé des articles intéressants et googling pour des avantages pratiques. Voici quelques liens:
5 Réponses :
Le principal avantage est que votre base de données ne finira pas de manière incompatible si votre code client buggy essaie de faire quelque chose de mal. Les clés étrangères sont un type de «contrainte», c'est ainsi que vous devriez les utiliser.
Ils n'ont pas d'avantage "fonctionnel", ils n'imposeront rien. Vous devez toujours créer vous-même des index vous-même, etc. et oui, vous pouvez avoir des valeurs nulles dans une colonne qui est une clé étrangère.
Pas seulement le code client buggy. Les utilisateurs "Buggy" et les administrateurs de base de données ont été connus pour faire des erreurs lors d'une solution rapide en tapant directement des commandes de mise à jour SQL!
Les contraintes FK maintiennent vos données cohérentes. C'est ça. C'est le principal avantage. Les contraintes FK ne vous fourniront aucun gain de performance.
Mais, sauf si vous avez désormais dénormalisé la structure de la DB, je vous recommanderais d'utiliser des contraintes FK. La raison principale - consistance.
J'ai géré certaines bases de données avec quelques millions de documents. Beaucoup tourne autour de l'importation de données entre la base de données et son clone, puis en utilisant ce clone dans l'environnement Web-App. Eh bien, j'ai connu que gardant automatiquement les index PK et contribue donc à accélérer l'accès des données. Maintenant, à partir de cette discussion, je dérange que si j'utilise des jointures dans mes requêtes SQL, j'utilise FK et l'indice pour rendre les opérations de jointure efficaces.
Par exemple, j'ai une table orgmaster (contient tous les enregistrements ORG) puis j'ai une table de réservation (contient tous les enregistrements de réservation). Maintenant, l'orgmaster.id est "référencé" comme réservationmaster.orgid. Donc, j'ai un FK pour la relation orgide-to-id et je ... l'indice «Index» pour une meilleure performance de toute opération de jointure entre ces deux tables .. Est-ce que je l'ai eu correctement?
Tout ce qui précède - au coût des frais supplémentaires de l'espace et de l'heure (tout en insérant un enregistrement dans la table avec FK).
Je demanderais que vous me fournissiez une liste de points à prendre en compte, comme - - - est-ce que FK-Index va manger trop d'espace \ Time à mesure que la table augmente de quelques millions d'enregistrements? - Dans ce cas, cela vaut-il la peine d'aller pour un indice FK "à chaque fois"? - Dans quelle cas shud je n'applique pas de FK ou d'indexer ou n'abandonnez-la pas (bien sûr, je ne peux pas gérer beaucoup de l'application) - toute autre chose délicate pour accélérer la jointure ou d'autres recherches de temps?
Comme mentionné, ils sont pour l'intégrité des données. Toute "perte" de performance serait complètement effacée par le temps nécessaire pour corriger les données cassées.
Cependant, il pourrait y avoir une prestation de performance indirecte.
Pour SQL Server au moins, les colonnes du FK doivent avoir le même type de données de chaque côté. Sans FK, vous pourriez avoir un parent nvarchar et un enfant de Varchar, par exemple. Lorsque vous rejoignez les 2 tables, vous obtiendrez des conversions de données de données pouvant tuer des performances.
Exemple: Différentes longueurs varchariennes provoquant un Numéro
J'ai lu au moins un exemple sur le net où il a été montré que les touches étrangères sont les performances, car l'optimisateur ne doit pas nécessairement faire des chèques supplémentaires sur des tables, car il sait que les données répondent à certains critères déjà dus au fk. Désolé, je n'ai pas de lien mais le blog a donné une production détaillée des plans de requête pour le prouver.