Je travaille sur une ancienne application Web Ma société utilise pour créer des enquêtes. J'ai examiné le schéma de base de données via l'invite de commande MySQL et j'ai pensé que les tables étaient assez solides. Bien que je ne sois pas un gourou DB, je suis bien versé dans la théorie derrière celle-ci (avoir pris quelques cours de conception de la base de données dans mon programme d'ingénierie logicielle).
Cela étant dit, j'ai vidé les affirmations créées dans un fichier SQL et les a importés dans MySQL Workbench et a vu qu'ils ne font aucune utilisation de clés étrangères "réelles". Ils stockeront la clé primaire d'une autre table comme si vous le feriez avec un FK, mais ils ne le déclarent pas comme un.
Voyant ainsi comment leur DB est conçu comme je voudrais par le biais de ce que je sais (moins le problème du FK), je me suis laissé, il y a peut-être une raison derrière cela. Est-ce un cas de programmation paresseuse ou pourriez-vous obtenir des gains de performance en faisant toute la vérification des erreurs par programme?
Si vous souhaitez un exemple, ils ont essentiellement des enquêtes et une enquête a une série de questions. Une question fait partie d'une enquête afin qu'elle détient sa pk dans une colonne. C'est à peu près beaucoup, mais ils l'utilisent partout.
J'apprécierais toute idée :) (Je comprends que cette question pourrait ne pas avoir une bonne / mauvaise réponse, mais je cherche davantage pour des informations sur la raison pour laquelle ils le feraient comme ce système a été assez solide depuis que nous commencé à utiliser, donc je suis amené à croire que ces gars savaient ce qu'ils faisaient)
6 Réponses :
MySQL ne supporte que la définition des relations clés étrangères réelles sur les tables d'innoDB, peut-être que les vôtres sont Myisam ou autre chose?
Plus important est que les colonnes appropriées ont des indices définis sur eux (afin que la PK d'une autre table soit indexée). Ceci est également possible dans Myisam.
Les développeurs d'origine ont peut-être choisi d'utiliser myisam ou tout autre moteur de stockage qui ne prend pas en charge Contraintes de clés étrangères.
C'est exactement ce que c'est. Je pourrais peut-être concevoir quelque chose sur papier, mais je manque certainement dans le service de la pratique. Merci beaucoup de gars :)
Juste comme une note latérale, MySQL a soutenu les clés étrangères pour Innodb depuis la version 3.23.44. Source: en.wikipedia.org/wiki/mysql#future_relases
J'utilise MySQL Workbench pour créer mon schéma, puis exporter mes déclarations. Je vais toujours choisir innodb comme mon moteur de stockage, pourquoi je ne savais pas que Myisam n'a pas soutenu FKS du tout.
Et si vous souhaitez utiliser les fonctionnalités de recherche de texte intégral spécifiques MySQL, vous devez utiliser Myisam, cela ne fonctionne pas avec InnoDB (ou tout autre type de table à ce sujet) ...
Et c'est aussi bonne raison de ne pas utiliser MySQL comme autre que j'ai vu.
Vous n'avez pas vraiment à utiliser des clés étrangères.
Si vous ne les avez pas, les données peuvent être devenues incohérentes et vous ne pourrez pas utiliser les suppressions et les mises à jour de cascade.
Si vous les avez pourriez perdre certaines des données des utilisateurs en raison du bogue dans vos déclarations SQL qui se produisent en raison des changements de schéma.
Certains préfèrent les avoir, certains préfèrent la vie sans eux. Il n'y a pas de véritables avantages dans les deux cas.
Je dirais que la cohérence des données est un véritable avantage.
@simon, pas vraiment. Vous aurez probablement probablement juste des lignes supplémentaires mentantes qui ne vous dérangent pas beaucoup comme elles seront invisibles pour la plupart des requêtes. D'autre part, ces lignes cachées peuvent avoir des informations essentielles à l'utilisateur.
Mais il ne s'agit pas seulement d'appliquer la suppression sur les objets enfants abandonnés. Appliquer la cohérence des données avec les clés étrangères empêche également de nombreuses erreurs, comme la modification des touches des objets référencés aux valeurs inexistantes (qui sont souvent impossibles ou très difficiles à corriger après l'accident). Et si vous pensez que certaines informations doivent être stockées à des fins historiques, il existe de meilleurs moyens que de laisser les clés étrangères.
@simon, cela vous évite également des ennuis lorsque vous devez faire des références circulaires. J'ai vécu avec eux pendant 5 ans et sans eux pendant 2 ans et franchement je ne vois aucune différence. Sauf que je n'ai pas à penser dans quel ordre devrais-je mettre des données dans des tables afin de ne pas exploser mon visage.
sur les grandes bases de données Uber (le type que Teradata supporte), vous constatez qu'ils n'utilisent pas les clés étrangères. La raison est la performance. Chaque fois que vous écrivez à la base de données, ce qui est assez souvent dans un entrepôt de données, vous avez les frais généraux supplémentaires de devoir vérifier tous les FK sur une table. Si vous le savez déjà, c'est vrai, quel est le point.
Un bon design sur une petite dB signifierait que vous les mettiez dans, mais il y a des gains de performance à avoir en laissant tomber.
Merci. C'est quelque chose que je me demandais. Je pense que leur base de données a un nombre suffisant de tables qui gardent une trace de "FKS" serait suffisamment facile.
Voici une instance de vie réelle où je n'utilise pas une clé étrangère.
J'avais besoin d'un moyen de stocker une relation d'enfant parent où l'enfant peut ne pas exister et que l'enfant est une classe abstraite. Étant donné que l'enfant pourrait être de quelques types, j'utilise un champ pour nommer le type de l'enfant et un champ pour répertorier l'ID de l'enfant. L'application gère la majeure partie de la logique.
Je ne suis pas sûr que c'était la meilleure décision de conception, mais c'était le meilleur que je puisse trouver sous la date limite. Ça marche bien jusqu'à présent!
comme des points généraux; Les touches accélère les lectures (s'ils sont applicables à la lecture de la lecture, ils aident l'optimiseur) et ralentir les écrires (car ils ajoutent des frais généraux aux tables).
Dans la grande majorité des cas, l'amélioration de la vitesse de lecture et de maintenance de l'intégrité référentielle l'emporte sur les surcharges mineures qu'ils ajoutent aux écritures.
Cette distinction a été floue en cacheting, à la mise en miroir, etc. comme tant de lectures sur les très grands sites n'appuyèrent pas réellement la base de données "Live" - mais cela n'est pas très pertinent, sauf si vous travaillez pour Amazon, Twitter ou similaire .