Contraintes d'intégrité dans une base de données relationnelle - devrions-nous les oublier?

Question

Je suis dans une discussion permanente avec les développeurs de la société où je travaille parce qu'ils disent qu'il est préférable de se débarrasser de la mise en œuvre des relations (via des définitions de contrainte de clé étrangère) dans une base de données relationnelle afin d'accélérer les grandes requêtes et de mieux gagner performance.

La plate-forme considérée est MySQL 5.x, et aucune clé étrangère n'a été mise en place, même certaines contraintes principales des tables pertinentes sont manquantes qui, du moins pour moi, n'est pas raisonnable. Peut-être qu'ils ont raison et je me trompe, mais je n'ai pas assez d'arguments pour discuter de cette situation.

Cela a été l'approche préférée pendant trois ans maintenant. Je suis nouveau dans cette société (un mois seulement) mais, comme le produit "fonctionne", il y a une hésitation pour améliorer la base de données; Néanmoins, la première chose que j'ai remarquée est une page prenant 1 minute à charger (oui, 60 secondes!).

L'une des revendications de la situation actuelle est qu'une base de données "dénormalisée" est plus rapide qu'une base de données normalisée, mais je ne crois pas que ce soit vrai.

La plupart des requêtes pertinentes comprennent les opérations de jointure, ce qui les rend très longs très lents avec de grandes quantités de données (la base de données contient des millions de lignes).

En commun, le traitement des opérations "CRUD" est mis en œuvre au niveau du code du programme d'application; Par exemple, afin de supprimer certaines données de, disons, TableA:

il est nécessaire de commencer par vérifier à la volée S'il existe une relation entre les lignes de TableA et TableB,
si ladite relation est "détectée", le code du programme d'applications ne permettra pas de supprimer la ou les lignes locales pertinentes, mais
si, pour une raison quelconque, le code du programme d'applications échoue, l'opération de suppression "réussira", peu importe s'il existe une relation concernant les lignes et les tables impliquées.

Question

Pourriez-vous m'aider à élaborer une bonne et une bonne réponse solide pour enrichir le débat?

_{Note: Peut-être que quelque chose comme cela a été posé (et répondit) avant, mais je n'ai rien trouvé au moyen de Google.}

MDCCL · Accepted Answer

Si, comme indiqué dans votre message, l'intention est de créer un relationnelle Base de données (RDB pour la brièveté) et, par conséquent, il est prévu qu'elle fonctionne comme telle, la réponse courte est la suivante:

Non, vous ne devez pas négliger les contraintes d'intégrité des données.

L'objectif principal devrait être de gérer les données pertinentes telles que, un actif organisationnel assez utile et une manière fiable à atteindre ledit objectif consiste à utiliser des moyens techniques supportés par la théorie du son.

Ainsi, en tant que professionnels de la base de données, vous pouvez tirer parti des mécanismes de pointe et élégant modèle relationnel fourni par DR. CODD EF pour appliquer les règles commerciales et Évitez les problèmes qui se poseraient éventuellement si elles ne sont pas utilisées.

À cet égard, je partagerai (a) mon objectif général de prendre des contraintes et également (b) plusieurs considérations sur l'état des choses de la base de données et de l'environnement de travail en cause comme suit.

Contraintes de clés étrangères, relations de données et intégrité référentielle

Un RDB doit refléter les caractéristiques du contexte commercial d'intérêt avec une grande précision, ce qui nécessite définitivement un fichier en profondeur niveau conceptuel Analyse dirigée par un modeleur ou un concepteur qui suit les meilleures pratiques, compte avec le Assistance indispensable des experts en entreprise. Cette analyse doit générer l'identification et la formulation correcte des règles applicables règles métier.

Par conséquent, si un tel modélisant a identifié qu'il existe des interrelations entre les données de pertinence, il doit configurer le niveau logique restrictions de sorte que le système de gestion de base de données (SGBD) puisse garantir que Les données restent compatibles avec les caractéristiques et règles exactes déterminées dans l'analyse mentionnée ci-dessus en tout temps.

En ce qui concerne la base de données en discussion, on peut déduire que les interrelations pertinentes ont été identifiées, car vous avez mentionné qu'il existe une tentative de procédure (et facile à contourner) de les appliquer de l'extérieur des installations de la SGBD, à la demande de code de programme d'application (qui est une approche pré-relationnelle) que, dans tous les cas, doit "toucher" la base de données pour tenter de valider la totalité desdites interrelations.

Cependant, comme vous le savez, ce n'est pas la technique optimale de protéger Intégrité référentielle, car la science relationnelle a prescrit un instrument très puissant à cette fin, c'est-à-dire des contraintes de clé étrangère (FK). Ces contraintes sont très faciles à créer (via l'approche déclarative supérieure) telles qu'elles sont célibataires phrases Évitez de recourir à des procédures ad hoc inutiles et exposées aux erreurs. Il est très utile de noter que la vitesse d'exécution des contraintes FK a été très optimisée par des programmeurs spécialisés (et les principaux fournisseurs de plateformes ont travaillé dessus pour des décennies même).

En outre, étant donné qu'une RDB doit être un composant logiciel indépendant (auto-protecteur, auto-décrivant, etc.) capable d'être accédé par plusieurs programmes d'application (bureau, automatiques, Web, mobiles, combinaisons), il ne devrait pas être "Couplé" avec le code de l'une de ces applications.

De même, la création de données une ressource organisationnelle significative tend naturellement à des programmes d'application sur les plats, aux programmeurs d'application, aux plateformes de développement d'applications et aux paradigmes de programmation.

Principales contraintes clés et implications des lignes en double

Quand -conceptuellement parler - un particulier genre de chose a été jugé de signification dans un environnement commercial, une base de données doit (1) déterminer ses caractéristiques pertinentes -ie, ses propriétés -, confirmer. genre de chose En tant qu'instances d'entité prototype -ie, un type d'entité - et (2) le représente à titre d'un Tableau intégré par un ou plusieurs colonnes dans une conception logique.

Ensuite, comme il s'agit de primot Pour distinguer chaque individu instance d'un type d'entité donné dans le monde réel, chacun rangée = ci-joint dans un table doit aussi être distingué aussi bien. Si une table n'a pas de clé déclarée, elle conservera éventuellement des doublons et s'il y a deux lignes ou plus qui conservent exactement les mêmes valeurs, elles portent toutes les mêmes Signification, ils représentent le même fait.

Sur ce point, des lignes en double doivent être rejetées en raison de plusieurs raisons. À partir d'une perspective théorique, le concepteur doit s'assurer que chaque ligne est toujours unique dans le but d'avoir des tables qui fonctionnent de manière relative que le permis de sous-langage de données SQL (ayant des répercussions importantes sur les opérations de manipulation de données). En outre, à partir d'une perspective d'information, si plusieurs lignes représentent le même fait, leur enregistrement est non seulement superflu mais nocif, comme ci-dessous.

Supposons que quelqu'un ait inséré deux rangées identiques dans une certaine table.
Plus tard, quelqu'un d'autre vient et ne met à jour qu'une seule apparition des duplicats. En conséquence, l'autre occurrence n'est plus à jour.
Successivement, une autre personne met à jour l'événement qui n'avait pas été modifié jusqu'à présent. De cette manière, les deux doublons ont subi des changements différents à des moments distincts à temps.
Après cela, lorsque quelqu'un souhaite la sélection des informations véhiculées par les lignes en question, il peut trouver deux "versions" différentes de celui-ci.

De cette façon:

Quelle "version" peut être considérée comme la bonne et fiable?
Lequel reflète le monde réel avec précision?

Comme vous le savez, ce phénomène peut même avoir des implications juridiques, une circonstance qui revêt une importance énorme.

En outre, le temps et les efforts qui doivent être utilisés pour gérer de telles contradictions (peut-être par une sorte de "synchronisation de mise à jour") devraient mieux être consacrés aux tâches qui produisent une valeur de votre organisation. Ainsi, la conservation des lignes contradictoires doit être évitée par conception Pour conserver la cohérence d'une base de données intacte.

C'est pourquoi l'identification d'une clé primaire (PK) et La déclaration de la contrainte correspondante devrait TOUJOURS être effectuée par le concepteur de base de données. Mais il faut également mentionner qu'une table peut avoir plus d'une colonne ou une combinaison de colonnes qui détiennent des valeurs qui identifient de manière unique chaque ligne; En conséquence, outre la mise en place d'une contrainte PK (idéalement établie comme primaire en raison de raisons pragmatiques), le concepteur doit aussi bien déclarer une ou plusieurs touches alternatives (généralement définies via une ou plusieurs contraintes uniques et plus non nulles) lorsqu'elle s'applique (ce qui est joli commun).

Une autre propriété avantageuse de PKS est que, lorsque "migré" vers d'autres tables pour participer à des fks simples ou composites, ils peuvent aider à appliquer les cardinalité des ratios des relations qui existent entre les données. Tout cela, oui, au moyen de paramètres déclaratifs simples et efficaces, assurés par le SGBD.

(Courant) Vérifier les contraintes et la validation à une ligne

N'oublions pas de la pertinence des contraintes de vérification (actuelles) qui, en limitant le jeu valide des valeurs de colonne valides d'une ligne (qui peut sembler simple, mais constitue en fait une caractéristique fondamentale d'un SGBD relationnel), aidez-la aussi bien à faire Selon que les règles du contexte commercial sont reflétées avec précision à tout moment.

Lorsque vous avez marqué votre question avec la balise MySQL, il faut mentionner que, malheureusement, une telle plate-forme permet la déclaration de ce type de contrainte, mais, en même temps, ignore son application! , situation , naturellement, a été signalé comme un bogue depuis 2004 .

À cet égard, vous devriez vous occuper de ce facteur par d'autres moyens, par exemple transactions acides , déclencheurs ou d'autres méthodes au sein de la SGBD elle-même (voir cette réponse par @ ypercubeᵀᴹ Pour plus d'informations sur ce sujet) afin que les données continuent à être cohérentes.

Contraintes d'affirmation: Configuration des règles commerciales multiples et multi-tableaux de multiples lignes déclaratives

Un aspect que pour toutes les raisons est très mal soutenu --Si à tous les différents SQL DBMSS, y compris MySQL, permet de faciliter des contraintes multi-rangées et multi-table dans une mode déclarative -Beyond PKS et FKS, évidemment.

Pour sa part, la norme SQL inclut des assertions de nombreuses années maintenant. Je ne sais pas quelles règles de votre environnement commercial bénéficieraient de cette approche de validation au niveau logique mais, en tant que concepteur de base de données, je considère que cela serait assez pratique de contraindre les données avec une ou plusieurs affirmations, bien que je doive mentionner cela de la Point de vue des développeurs DBMS, ce type d'outil primordial a été difficile à mettre en œuvre au niveau physique de l'abstraction.

Il semble que le fournisseur d'oracle et/ou les développeurs évaluent Support d'affirmation depuis 2016, ce qui rendrait la conformité à la SGBD plus relativement et, par conséquent, plus robuste et plus compétitive. Je suppose que si (i) leurs consommateurs continuent de pousser et (ii) oracle réussit dans la mise en œuvre, puis (iii) d'autres vendeurs/communautés de la SGBD devront également leur permettre, et leur utilisation commencera à se propager. Ce serait certainement des progrès énormes dans le domaine de la gestion de la base de données et constitueraient l'un des outils les plus distinctifs envisagés par le Dr. Doctor, j'espère personnellement que nous allons voir que cela se passe bientôt.

Cohérence des données et processus de prise de décision

Comme indiqué ci-dessus, l'un des aspects les plus importants d'une RDB est qu'il garantit par lui-même le cohérence des données qu'il conserve, et ladite consistance n'est remplie que lorsque la RDB est conforme aux contraintes d'intégrité. déclaré par le modeleur.

À cet égard, il est obligatoire d'avoir base Tables (celles établies dans une structure DDL) Quelle intégrité est protégée afin de pouvoir créer dérivé Tables (par exemple, une instruction SELECT ou une vue qui récupère des colonnes à partir de plusieurs tables) qui sont Fikeworthy, car des tables dérivées doivent être produites nécessairement en termes de tables de base.

Il est bien connu que les gens utilisent des informations comme un outil principal dans le processus décisionnel organisationnel (et dans le commun). Ensuite, si les informations présentées par une base de données n'étaient pas cohérentes et précises, les décisions basées sur de telles informations ne seront pas dues (pour le moindre). C'est pourquoi un RDB doit être soigneusement conçu et mis en œuvre: il devrait être construit pour devenir une ressource fiable pouvant aider ses utilisateurs à prendre des décisions bien fondées.

"Dénormalisation"

Hélas, "Une base de données" dénormalisée "est plus rapide que la normalisation" est une idée fausse largement répandue, bien que ce soit également un argument qui peut être réfuté sur des motifs logiques, physiques et pragmatiques.

Tout d'abord, dénormalisation implique nécessairement qu'une table de base a été préalablement normalisée (en vertu de A formel, procédure scientifique, remplie au niveau logique de l'abstraction d'une base de données).

Ainsi, en supposant que ladite table était en réalité normalisé correctement, "dénormaliser" cela (qui contraste avec la signification formelle du mot, implique l'adjointe des colonnes informatiques qui appartiennent et font également partie des autres tables dans un = ad hoc mode) pourrait aider, par exemple, pour accélérer (au niveau physique), le traitement d'une seule ou quelques instructions de sélection particulières, tandis que ce plan d'action pourrait, en même temps, saper l'exécution de nombreuses autres opérations de manipulation de données associées (par exemple, plusieurs instructions, supprimées, supprimez et sélectionnez des instructions, ou des combinaisons d'entre elles dans une seule ou plusieurs transactions acides).

En outre, la dénormalisation (qu'elle est formelle ou informelle) introduirait Anomalies de mise à jour/modification qui détériorent la cohérence de la base de données, un problème qui "peut" être géré par un complexe, coûteux et sujet à des erreurs procédures, lorsque tout cela peut être empêché dès le début.

Echafaudages de niveau physique prenant en charge les tables normalisées et "dénormalisées"

Une disposition logique (résumé) (conception SQL-DDL) destinée à être utilisée dans le monde réel détient clairement des répercussions physiques (concrètes) qui doivent être envisagées.

De cette manière, une table "dénormalisation" serait nécessairement "plus large" (tenant des colonnes supplémentaires), ce qui signifie que ses rangées seraient nécessairement plus lourdes (nécessitant des composants physiques plus importants), donc Cela signifie que les processus informatiques sous-jacents (par exemple, ceux qui ont à voir avec le disque dur ou la mémoire) peuvent facilement tourner plus lentement.

En revanche, une table normalisée qui est bien sûr "plus étroite" (ayant moins de colonnes) serait un élément "plus léger" (servi par des composants physiques moins petits) qui "se comporte plus rapidement", ce qui accélérerait la série d'actions liées à , par exemple, la rédaction de données et la lecture.

Cela étant, il est très pratique de normaliser les tables pertinentes formellement et prudemment, les maintenir en tant que telles, puis (b) d'utiliser toute ressource de niveau physique pouvant optimiser la récupération de données et la vitesse de modification, par exemple la mise en œuvre Stratégie d'indexation minutieuse et efficace, permettant ainsi des configurations de serveur de logiciels et de matériel appropriées, à moderniser les capacités de bande passante du réseau, etc.

Le fonctionnement de la base de données à l'étude

Les paragraphes suivants de votre question ont à voir avec la rapidité des opérations de récupération de données:

[A] s le produit "fonctionne", il y a une hésitation pour améliorer la base de données; Néanmoins, la première chose que j'ai remarquée est une page prenant 1 minute à charger (oui, 60 secondes!).

Si la charge d'une certaine page prend beaucoup beaucoup, il est évident que les utilisateurs du système ne reçoivent pas de bon service; Par conséquent, même lorsqu'il "fonctionne", son fonctionnement ne semble pas être optimal du tout, point qui démontre que vos intentions pour rendre l'ensemble de l'environnement (base de données et applications) plus efficace sont bien soutenues et montre une attitude très constructive.

Puis, même lorsque la science vous soutient définitivement et que vous devriez donc conserver une posture ferme, je suggère d'aborder la situation de manière diplomatique, car à la fin de la journée, vos employeurs, vos employeurs, vos collègues et vos collègues se joignent à des efforts pour faire une organisation entière. plus de succès. Ainsi, c'est-à-dire qu'un argument selon lequel vous devriez souligner, alors qu'ils font d'autres choses plus que bien, l'amélioration de l'amélioration des pratiques générales de gestion des données peut considérablement aider à produire plus de croissance organisationnelle et individuelle.

La plupart des requêtes pertinentes comprennent les opérations de jointure, ce qui les rend très longs très lents avec de grandes quantités de données (la base de données contient des millions de lignes).

Il convient de noter que l'opérateur de jointure est un essentiel et puissant élément qui concerne la manipulation relationnelle des données. Ensuite, bien que des plateformes plus robustes le servent avec des exécutions comparativement plus rapides, les circonstances que vous décrivez sont probablement un symptôme d'une conception non électronique (aux niveaux conceptuels, logiques et physiques d'abstraction). Donc, mes estimations de première vue sont:

Les paramètres d'indice peuvent nécessiter une amélioration.
Les définitions de type colonne et de taille PK et FK doivent être examinées (et je suis totalement d'accord avec @ Rick James concernant son PK considérations , car les clés composites ont tendance à être beaucoup plus efficaces. que des substituts annexés dans les cas appropriés).
Une normalisation supplémentaire (formelle, basée sur la science) pourrait aider à atténuer ces problèmes, en raison du fait que, dans les bonnes circonstances (c'est-à-dire effectué dans une RDB bien conçue), joint sont exécutés très vite.

De plus, oui, comme @ Tommcatt mentionne dans sa réponse , parfois une réécriture (logique) d'une requête modifie son plan d'exécution (physique) accélérant la lecture/écriture de données, qui est un facteur qui devrait décider décidément être pris en compte.

TommCatt · Answer

La prémisse de base de vos développeurs est absolument fausse. Les clés étrangères auront un impact légèrement les performances du DML de votre système. ils ne sont pas utilisés du tout dans les requêtes Ainsi n'a donc aucun effet sur leur performance. Donc, vos développeurs ne savent pas ce qu'ils parlent et sont les toutes dernières personnes que vous devriez envisager de prendre conseil.

Les clés étrangères jouent un rôle essentiel dans le maintien de l'intégrité de vos données. Ceci est beaucoup plus important que toute nouvelle amélioration de la performance gagnée en les éliminant (même celles qui étaient vraies).

Ne faites pas, sous aucune circonstances, supprimez FKS d'un OLTP Database.

En outre, la dénormalisation accélérera parfois certaines requêtes. Comme on dit, cela dépend. Néanmoins, même s'il y a une certaine amélioration de la vitesse, il ne vaut généralement pas l'effort supplémentaire pour maintenir l'intégrité des données.

Il est très rare lorsque le réglage simple ne peut pas vous obtenir beaucoup plus de vitesse que de dénormalisation. C'est là qu'un bon dba peut (enfin) gagner sa rémunération. Vous pouvez également régler vos requêtes. Une fois, j'ai pris une requête qui a renvoyé une réponse au moins 30 minutes et je l'ai eu pour travailler en moins de 8 secondes. Aucune modification de la base de données, il suffit de réécrire la requête. Certes, c'est mon meilleur disque personnel, votre kilométrage peut donc varier, mais la dénormalisation devrait être la toute dernière chose que vous essayez.

Vous pouvez également conserver les requêtes les plus complexes d'être écrites par les développeurs. Demandez-leur quelles données elles veulent et dans quel format ils le souhaitent. Ensuite fournir des vues pour leur donner. Les requêtes compliquées seront les points de vue. Les développeurs doivent alors seulement écrire:

select <something> from <SomeView> where <whatever>;

Je suppose également que votre base de données est également bien conçue. Une mauvaise conception de la base de données, voire de petites parties, peut vraiment ralentir les choses. J'ai souvent travaillé avec de très grandes tables (milliards d'enregistrements chacun) avec des requêtes qui les ont rejoints ensemble à gauche et à droite et attendues (et ont) réponses dans des fractions d'une seconde. La taille d'une table n'est pas déterminante de la vitesse de la requête.

Je crains vraiment quand quelqu'un dit: "Parce que le produit" fonctionne ", il y a une hésitation pour améliorer la base de données." Si cette "hésitation" ressemble plus à "Pas sur ma montre, Pal!" Ensuite, vous pouvez même vouloir commencer à mettre à jour votre CV. Rien de bon ne vient jamais d'un tel environnement et vous obtiendrez le blâme pour chaque échec futur, même si vous avez peut-être suffipé pendant des heures pour effectuer un changement qui aurait empêché l'échec. Vous entendrez que vous entendrez: "Le moment n'est pas un bon moment pour apporter des changements" encore et encore. Droite. Bonne chance.

Rick James · Answer

Changer le titre change la question. FOREIGN KEYs sont facultatifs. Ils font:

Un FK crée implicitement un INDEX dans l'une des tables. Un tel index peut être ajouté manuellement. (SO FK n'est pas requis pour cela.)
Un FK vérifie l'intégrité. C'est la prétention principale de FK à la gloire. Un FK n'est pas requis puisque votre application peut effectuer des chèques similaires ou décider qu'un chèque n'est pas nécessaire. Alors...
Le chèque d'intégrité coûte quelque chose en performance; Donc, il ralentit le traitement. (Ce n'est généralement pas une grosse affaire.)
Fks ne fais pas tout ce que tout le monde veut; Ce forum est jonché de "pourquoi ne peut pas faire x" questions. En particulier, l'option CHECK n'est pas agiée.
Fks peut CASCADE choses. (Personnellement, je préfère rester en contrôle et ne pas supposer que le FK "faire la bonne chose".)

Bottom Line pour FKS: Certaines personnes insistent sur FKS; Certains produits vivent parfaitement sans eux. Tu décides.

Se débarrasser de PRIMARY KEY à Innodb est une grosse erreur. D'autre part, se débarrasser d'un substitut AUTO_INCREMENT Et en utilisant un PK "naturel" composé d'une (ou plus) colonnes est souvent le droite chose à faire. Un cas simple, commun, est un nombre élevé: de nombreuses table de mappage, comme indiqué ( ici .

Basé sur une expérience personnelle, je suggère que le chapeau 2/3 des tables vaut mieux utiliser "naturel" au lieu de Auto_inc Pk.