Contraintes FOREIGN KEY SQL vs code client
Qui n'a jamais débattu avec un collègue sur l'utilité de l'utilisation ou non de clés étrangères dans le SGBD.
Ce nouveau tutoriel de sqlpro nous permet d'aborder ce sujet à partir de cas pratiques.
http://sqlpro.developpez.com/article/fk-sql-vs-appli/
Et vous ce tutoriel vous a-t-il convaincu ?
:fleche: Retrouvez tous les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server
Ne confondons pas logique formelle et fer à souder
Citation:
Envoyé par
Waldar
Je pense que Jester parlait d'insérer dans une table client une ligne CLIENT INCONNU avec un code reconnaissable ('.' ou -1 par exemple) sur laquelle faire pointer du CA.
On reste alors dans une relation PK/FK classique, le CA est bien représenté dans les tableaux de bord des directeurs, et rien n'empêche une alimentation ultérieure de corriger la donnée.
Avez-vous tenu compte du sens de ce que j’ai écrit ? Quand pour votre part vous écrivez : « On reste alors dans une relation PK/FK classique », certes, à la lettre cela marche, mais ne convient pas dans l’esprit, car en l’occurrence on passe dans une toute autre dimension. Je répète qu’on ne doit pas détourner la finalité de la relation PK/FK pour un bricolage technique de circonstance réalisé a posteriori, à la va-vite. En bon logicien, Ted Codd a défini l’intégrité référentielle en tenant compte fondamentalement de la dimension ontologique et sémantique des choses, et il est bon qu’à notre tour nous ne perdions pas de vue cette dimension. En conséquence, nous devons prendre en compte les situations du type « Contrat sans titulaire » et les exprimer dans le MCD (Modèle Conceptuel de Données) ou le DC (Diagramme de classes), et ne pas nous contenter systématiquement de cache-misère, corriger les données après remise des tableaux de bord (à moins que cette façon de procéder fasse l’objet de recettes ad-hoc, finissant par être érigées en une fort médiocre « théorie »...)