Mysql
 sql >> Base de données >  >> RDS >> Mysql

tableau fixe unique avec plusieurs colonnes vs tableaux abstraits flexibles

Certains problèmes doivent être clarifiés et résolus avant nous pouvons entrer dans une discussion raisonnable.

Résolution préalable

  1. Libellés
    Dans un métier qui demande de la précision, il est important que nous utilisions des étiquettes précises, pour éviter toute confusion, et pour pouvoir communiquer sans avoir à utiliser des descriptions et des qualificatifs interminables.

    Ce que vous avez publié en tant que FixedTables est non normalisé . Assez juste, il peut s'agir d'une tentative de troisième forme normale, mais en fait c'est un fichier plat, non normalisé (pas "dénormalisé). Ce que vous avez posté en tant que AbstractTables est, pour être précis, Entity-Attribute-Value , qui est presque, mais pas tout à fait, la sixième forme normale, et est donc plus normalisée que 3NF. En supposant que cela soit fait correctement, bien sûr.

    • Le fichier plat non normalisé n'est pas "dénormalisé". Il regorge de doublons (rien n'a été fait pour supprimer les groupes répétitifs et les colonnes en double ou pour résoudre les dépendances) et Nulls, c'est un porc de performance à bien des égards et empêche la concurrence.

    • Pour être dénormalisé, il doit d'abord être normalisé, puis la normalisation a reculé un peu pour une bonne raison. Puisqu'il n'est pas normalisé en premier lieu, il ne peut pas être dénormalisé. C'est simplement non normalisé.

    • On ne peut pas dire qu'il soit dénormalisé "pour la performance", car étant un porc de performance, c'est l'antithèse même de la performance. Eh bien, ils ont besoin d'une justification pour le manque de conception formalisée], et "pour la performance", c'est tout. Même le plus petit examen formel a révélé la fausse déclaration (mais très peu de gens peuvent fournir, donc il reste caché, jusqu'à ce qu'ils obtiennent un étranger pour résoudre, vous l'avez deviné, le problème de performance massif).

    • Les structures normalisées fonctionnent bien mieux que les structures non normalisées. Les structures plus normalisées (EAV/6NF) fonctionnent mieux que les structures moins normalisées (3NF/5NF).

    • Je suis d'accord avec l'idée maîtresse d'OMG Ponies, mais pas avec leurs étiquettes et leurs définitions

    • plutôt que de dire "ne "dénormalisez" pas à moins que vous ne le deviez" , je dis, "Normalisez fidèlement, point final" et 's'il y a un problème de performances, vous n'avez pas correctement normalisé' .

  2. Wikipédia
    Les entrées pour les formes normales et la normalisation proposent des définitions incorrectes ; ils confondent les Formes Normales; ils font défaut concernant le processus de Normalisation; et ils accordent un poids égal aux NF absurdes ou douteux qui ont été démystifiés il y a longtemps. Le résultat est que Wikipedia ajoute à un sujet déjà confus et rarement compris. Alors ne perdez pas votre temps.

    Cependant, pour progresser, sans que cette référence ne soit un obstacle, permettez-moi de dire ceci.

    • La définition de 3NF est stable et n'a pas changé.
    • Il y a beaucoup de confusion des NF entre 3NF et 5NF. La vérité est que c'est un domaine qui a progressé au cours des 15 dernières années; et de nombreuses organisations, universitaires ainsi que des fournisseurs avec leurs produits avec des limitations, ont sauté pour créer un nouveau "Formulaire normal" pour valider leurs offres. Tous servant des intérêts commerciaux et académiquement peu solides. 3NF dans son état d'origine non altéré destiné et garanti certains attributs.
    • La somme totale est, 5NF est aujourd'hui, ce que 3NF était censé être il y a 15 ans, et vous pouvez ignorer les plaisanteries commerciales et les quelque douze NF "spéciales" (commerciales et pseudo-académiques) entre les deux, certaines dont sont identifiés dans Wikipédia, et même cela en termes déroutants.

  3. Cinquième forme normale
    Puisque vous avez été en mesure de comprendre et de mettre en œuvre l'EAV dans votre message, vous n'aurez aucun problème à comprendre ce qui suit. Bien sûr, un vrai Modèle Relationnel est un pré-requis, des clés fortes, etc. La Cinquième Forme Normale l'est, puisque nous sautons la Quatrième :

    • Troisième forme normale
      • qui, en termes simples et définitifs, est que chaque colonne non clé de chaque table a une relation 1 ::1 avec la clé primaire de la table,
      • et à aucune autre colonne non clé
    • Aucune duplication de données (le résultat, si la normalisation progresse avec diligence ; n'est pas atteint par l'intelligence ou l'expérience seule, ou en y travaillant comme un objectif sans le processus formel)
    • pas d'anomalies de mise à jour (lorsque vous mettez à jour une colonne quelque part, vous n'êtes pas obligé de mettre à jour la même colonne située ailleurs ; la colonne existe à un et un seul endroit).
    • Si vous comprenez ce qui précède, 4NF, BCNF et tous les "NF" idiots peuvent être rejetés, ils sont nécessaires pour les systèmes d'archivage d'enregistrements physiques, tels que promus par les universitaires, assez étrangers au modèle relationnel (Codd).

  4. Sixième forme normale

    • L'objectif est l'élimination des données manquantes (colonnes d'attributs), c'est-à-dire l'élimination des valeurs nulles
    • C'est la seule véritable solution au problème des valeurs nulles (également appelée gestion des valeurs manquantes), et le résultat est une base de données sans valeurs nulles. (Cela peut être fait à 5NF avec des standards et des substituts Null mais ce n'est pas optimal.) La façon dont vous interprétez et affichez les valeurs manquantes est une autre histoire.
    • Techniquement, ce n'est pas une vraie forme normale, car elle n'a pas 5NF comme prérequis, mais elle a une valeur

  5. EAV vs sixième forme normale
    Toutes les bases de données que j'ai écrites, sauf une, sont en pur 5NF. J'ai travaillé avec (administré, corrigé, amélioré) quelques bases de données EAV et j'ai implémenté de nombreuses bases de données 6NF. EAV est une implémentation lâche de 6NF, souvent effectuée par des personnes qui ne maîtrisent pas bien la normalisation et les NF, mais qui peuvent voir la valeur et avoir besoin de la flexibilité de l'EAV. Vous êtes un parfait exemple.

    La différence est la suivante :parce que c'est lâche, et parce que les implémenteurs n'ont pas de référence (6NF) à laquelle être fidèle, ils n'implémentent que ce dont ils ont besoin, et ils écrivent tout en code; qui finit par être un modèle incohérent.

    Alors qu'une implémentation pure 6NF a un point de référence académique pur, et donc elle est généralement plus serrée et cohérente. Cela s'affiche généralement dans deux éléments visibles :

    • 6NF a un catalogue pour contenir les métadonnées, et tout est défini dans les métadonnées, pas dans le code. EAV n'en a pas, tout est dans le code (les implémenteurs gardent une trace des objets et des attributs). Évidemment, un catalogue facilite l'ajout de colonnes, la navigation et permet de former des utilitaires.
    • 6NF lorsqu'il est compris, fournit la vraie solution au problème nul. Les implémenteurs EAV, puisqu'ils sont absents du contexte 6NF, gèrent les données manquantes dans le code, de manière incohérente, ou pire, autorisent les valeurs nulles dans la base de données. Les implémenteurs 6NF interdisent les valeurs nulles et gèrent les données manquantes de manière cohérente et élégante, sans nécessiter de constructions de code (pour la gestion des valeurs nulles ; vous devez bien sûr encore coder pour les données manquantes).

Par exemple. Pour les bases de données 6NF avec un catalogue, j'ai un ensemble de procs qui [re]générera le SQL requis pour effectuer tous les SELECT, et je fournis des vues en 5NF pour tous les utilisateurs, afin qu'ils n'aient pas besoin de connaître ou de comprendre la structure 6NF sous-jacente . Ils sont chassés du catalogue. Ainsi, les changements sont faciles et automatisés. Les types EAV le font manuellement, en raison de l'absence de catalogue.

Discussion

Maintenant, nous pouvons commencer la discussion.

"Bien sûr, cela peut être plus abstrait si les valeurs sont prédéfinies (Exemple :les spécialités peuvent avoir leur propre liste)"

Bien sûr. Mais ne soyez pas trop "abstrait". Maintenez la cohérence et implémentez ces listes de la même manière EAV (ou 6NF) que les autres listes.

"Si j'adopte l'approche abstraite, cela peut être très flexible, mais les requêtes seront plus complexes avec beaucoup de jointures. Mais je ne sais pas si cela affecte les performances, l'exécution de ces requêtes 'plus complexes'."

  1. Les jointures sont piétonnes dans les bases de données relationnelles. Le problème n'est pas la base de données, le problème est que SQL est lourd lors de la gestion des jointures, en particulier des clés composées.

  2. Les bases de données EAV et 6NF ont plus de jointures, qui sont tout aussi piétonnes, ni plus, ni moins. Si vous devez coder chaque SELECT manuellement, bien sûr, la lourdeur devient vraiment lourde.

  3. L'ensemble du problème peut être éliminé en (a) optant pour 6NF sur EAV et (b) en implémentant un catalogue, à partir duquel vous pouvez (c) générer tout le SQL de base. Élimine également toute une classe d'erreurs.

  4. C'est un mythe courant que les jointures ont en quelque sorte un coût. Totalement faux.

    • La jointure est implémentée au moment de la compilation, il n'y a rien de substantiel pour "coûter" les cycles CPU.
    • Le problème est la taille des tableaux jointes, pas le coût de la jointure entre ces mêmes tables.
    • Joindre deux tables avec des millions de lignes chacune, sur une relation PK⇢FK correcte, chacune ayant les indices appropriés
      (Unique du côté parent [PK] ; Unique du côté enfant [PK=parent FK + quelque chose]
      est instantané
    • Lorsque l'index enfant n'est pas unique, mais qu'au moins les premières colonnes sont valides, il est plus lent ; là où il n'y a pas d'index utile, c'est bien sûr très lent.
    • Rien à voir avec le coût d'adhésion.
    • Lorsque de nombreuses lignes sont renvoyées, le goulot d'étranglement sera le réseau et la disposition du disque ; pas le traitement de jointure.

  5. Par conséquent, vous pouvez devenir aussi "complexe" que vous le souhaitez, il n'y a aucun coût, SQL peut le gérer.

Je serais intéressé de savoir quels sont les avantages et les inconvénients des deux méthodes. Je peux juste imaginer par moi-même, mais je n'ai pas l'expérience pour le confirmer.

  1. 5NF (ou 3NF pour ceux qui n'ont pas fait la progression) est le plus simple et le meilleur, en termes de mise en œuvre; facilité d'utilisation (développeurs comme utilisateurs) ; et entretien.

    • L'inconvénient est qu'à chaque fois que vous ajoutez une colonne, vous devez modifier la structure de la base de données (table DDL). C'est bien dans certains cas, mais pas dans la plupart des cas, en raison du contrôle des modifications en place, assez onéreux.
    • Deuxièmement, vous devez modifier le code existant (le code gérant la nouvelle colonne ne compte pas, car c'est un impératif) :là où de bons standards sont implémentés, cela est minimisé ; là où ils sont absents, la portée est imprévisible.

  2. EAV (c'est ce que vous avez posté), permet d'ajouter des colonnes sans modifications DDL. C'est la seule raison pour laquelle les gens le choisissent. (le code gérant la nouvelle colonne ne compte pas, car c'est un impératif). S'il est bien implémenté, cela n'affectera pas le code existant; sinon, ce sera le cas.

  3. Mais vous avez besoin de développeurs compatibles EAV.

    • Lorsque EAV est mal implémenté, c'est abominable, un pire gâchis que 5NF mal fait, mais pas pire que Non normalisé, ce que la plupart des bases de données existent (présenté à tort comme "dénormalisé pour les performances").
    • Bien sûr, il est encore plus important (que dans 5NF/3NF) de conserver un contexte Transaction fort, car les colonnes sont beaucoup plus distribuées.
    • De même, il est essentiel de conserver l'intégrité référentielle déclarative :les dégâts que j'ai constatés étaient dus en grande partie au fait que les développeurs ont supprimé DRI car il est devenu "trop ​​difficile à maintenir", le résultat a été, comme vous pouvez l'imaginer, une mère d'un tas de données avec des lignes et des colonnes 3NF/5NF en double partout. Et une gestion Null incohérente.

  4. Il n'y a aucune différence de performances, en supposant que le serveur a été raisonnablement configuré pour l'usage prévu. (Ok, il y a des optimisations spécifiques qui ne sont possibles que dans 6NF, qui ne sont pas possibles dans d'autres NF, mais je pense que cela sort du cadre de ce fil.) Et encore une fois, un EAV mal fait peut provoquer des goulots d'étranglement inutiles, pas plus que Non normalisé.

  5. Bien sûr, si vous optez pour EAV, je recommande plus de formalité; acheter le livre complet ; aller avec 6NF ; mettre en place un catalogue; utilitaires pour produire du SQL ; Vues ; gérer les données manquantes de manière cohérente ; éliminer complètement les nulls. Cela réduit votre vulnérabilité à la qualité de vos développeurs; ils peuvent oublier les problèmes ésotériques EAV/6NF, utiliser les vues et se concentrer sur la logique de l'application.