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

Conseils sur la structure de la base de données nécessaires

Tout d'abord, l'interface utilisateur : en tant qu'utilisateur, je déteste de rechercher un produit dans un catalogue organisé de manière strictement hiérarchique chemin. Je ne me souviens jamais dans quelle sous-sous-sous-sous-catégorie se trouve un produit "exotique" et cela m'oblige à perdre du temps à explorer des catégories "prometteurs" juste pour découvrir qu'il est classé dans une (pour moi, du moins ) façon étrange.

Qu'est-ce que Kevin Peno suggère est un bon conseil et est connu sous le nom de navigation à facettes . Comme Marcia Bates écrit dans Après la bombe à points :Récupérer correctement les informations Web cette fois , " .. la classification à facettes est à la classification hiérarchique ce que les bases de données relationnelles sont aux bases de données hiérarchiques. .. ".

Essentiellement, la recherche par facettes permet aux utilisateurs de rechercher dans votre catalogue à partir de la "facette" qu'ils préfèrent et de les laisser filtrer les informations en choisissant d'autres facettes tout au long de la recherche. Notez que, contrairement à la conception habituelle des systèmes de tags, rien ne vous empêche de hiérarchiser certaines de ces facettes.

Pour comprendre rapidement ce qu'est la recherche à facettes, il existe quelques démos à explorer sur The Flamenco Search Interface Project - Search Interfaces that Flow .

Deuxièmement, la logique de l'application : ce que Manitra propose est aussi un bon conseil (si je comprends bien), c'est-à-dire séparer les nodes et links d'un arbre/graphe dans différentes relations. Ce qu'il appelle "table des ancêtres" (qui est un nom beaucoup plus intuitif, cependant) est connu sous le nom de fermeture transitive d'un graphe orienté acyclique (DAG) (relation d'accessibilité). Au-delà des performances, cela simplifie grandement les requêtes, comme l'a dit Manitra.

Mais Je suggère une vue pour une telle "table des ancêtres" (fermeture transitive), afin que les mises à jour soient en temps réel et incrémentielles, et non périodiques par un travail par lots. Il y a du code SQL (mais je pense qu'il doit être adapté un peu à des SGBD spécifiques) dans les articles que j'ai mentionnés dans ma réponse à langage de requête pour les ensembles de graphes :question sur la modélisation des données . En particulier, regardez Maintenir la fermeture transitive des graphes en SQL (.ps - post-scriptum).

Relation produits-catégories

Le premier point de Manitra mérite également d'être souligné.

Ce qu'il dit, c'est qu'entre les produits et les catégories, il existe une relation plusieurs à plusieurs. C'est-à-dire :chaque produit peut appartenir à une ou plusieurs catégories et dans chaque catégorie, il peut y avoir zéro ou plusieurs produits.

Compte tenu des variables de relation (relvars) Products et Categories, cette relation peut être représentée, par exemple, sous la forme d'un relvar PC avec au moins les attributs P# et C#, c'est-à-dire les numéros de produit et de catégorie (identifiants) dans une relation de clé étrangère avec les produits et catégories correspondants. nombres.

Ceci est complémentaire à la gestion des hiérarchies de catégories. Bien sûr, ceci n'est qu'une esquisse de conception.

Sur la navigation à facettes en SQL

Un concept utile pour implémenter la "navigation à facettes" est la division relationnelle , ou encore des des comparaisons relationnelles (voir en bas de la page liée). C'est à dire. en divisant PC (Produits-Catégories) par une liste (croissante) de catégories choisies par un utilisateur (navigation par facettes), on n'obtient que des produits dans ces catégories (bien sûr, les catégories sont présumées non tous mutuellement exclusifs, sinon en choisissant deux catégories on obtiendra zéro produit).

Les SGBD basés sur SQL manquent généralement de ces opérateurs (division et comparaisons), je donne donc ci-dessous quelques articles intéressants qui les implémentent/discutent :

et ainsi de suite...

Je n'entrerai pas dans les détails ici mais l'interaction entre les hiérarchies de catégories et la navigation par facette nécessite une attention particulière.

Une digression sur la "planéité"

J'ai brièvement regardé l'article lié par Pras , Gestion des données hiérarchiques dans MySQL , mais j'ai arrêté de lire après ces quelques lignes dans l'introduction :

Pour comprendre pourquoi cette insistance sur la planéité des relations est juste un non-sens , imaginez un cube dans un système de coordonnées cartésien tridimensionnel :il sera identifié par 8 coordonnées (triplets), disons P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [ici nous ne nous intéressons pas à contraintes sur ces coordonnées pour qu'elles représentent réellement un cube].

Maintenant, nous allons mettre ces ensembles de coordonnées (points) dans une variable de relation et nous nommerons cette variable Points . Nous allons représenter la valeur de relation des Points sous forme de tableau ci-dessous :

Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

Est-ce que ce cube est "aplati" par le simple fait de le représenter sous forme de tableau ? Une relation (valeur) est-elle la même chose que sa représentation tabulaire ?

Une variable de relation prend comme valeurs des ensembles de points dans un espace discret à n dimensions, où n est le nombre d'attributs de relation ("colonnes"). Que signifie, pour un espace discret à n dimensions, être « plat » ? Juste un non-sens, comme je l'ai écrit ci-dessus.

Ne vous méprenez pas, il est certainement vrai que SQL est un langage mal conçu et que les SGBD basés sur SQL sont pleins d'idiosyncrasies et de lacunes (NULL, redondance, ...), en particulier les mauvais, le SGBD-as- type dumb-store (pas de contraintes référentielles, pas de contraintes d'intégrité, ...). Mais cela n'a rien à voir avec les limitations fantasmées des modèles de données relationnelles, bien au contraire :plus ils s'en détournent et pire est le résultat.

En particulier, le modèle de données relationnelles, une fois que vous l'avez compris, ne pose aucun problème pour représenter n'importe quelle structure, même les hiérarchies et les graphiques, comme je l'ai détaillé avec des références aux articles publiés mentionnés ci-dessus. Même SQL peut, si vous passez sous silence ses lacunes, passer à côté de quelque chose de mieux.

Sur le "modèle d'ensemble imbriqué"

J'ai parcouru le reste de cet article et je ne suis pas particulièrement impressionné par une conception aussi logique :elle suggère de confondre deux entités différentes, des nœuds et liens , dans une relation et cela causera probablement des maladresses. Mais je ne suis pas enclin à analyser cette conception plus en profondeur, désolé.

MODIF : Stephan Eggermont a objecté, dans les commentaires ci-dessous, que " Le modèle de liste plate est un problème. C'est une abstraction de l'implémentation qui rend la performance difficile à atteindre. ... ".

Maintenant, mon point est, précisément, que :

  1. ce "modèle de liste plate" est un fantaisie :ce n'est pas parce qu'on dispose (représente) des relations sous forme de tableaux ("listes plates") que les relations sont des "listes plates" (un "objet" et ses représentations ne sont pas la même chose) ;
  2. une représentation logique (relation) et des détails physiques de stockage (décompositions horizontales ou verticales, compression, index (hachages, b+tree, r-tree, ...) , clustering, partitionnement, etc.) sont distincts ; un des points du modèle relationnel de données (RDM ) est de dissocier le modèle logique du modèle "physique" (avec des avantages à la fois pour les utilisateurs et les implémenteurs de SGBD );
  3. les performances sont une conséquence directe des détails de stockage physique (mise en œuvre) et non de représentation logique (le commentaire d'Eggermont est un exemple classique de confusion logique-physique ).

Le modèle RDM ne contraint en aucune façon les implémentations ; on est libre d'implémenter des tuples et des relations comme on l'entend. Les relations ne sont pas nécessairement les fichiers et les tuples ne sont pas nécessairement enregistrements d'un dossier. Une telle correspondance est une stupide implémentation d'image directe .

Malheureusement, les implémentations de SGBD basées sur SQL sont , trop souvent, des implémentations stupides d'image directe et elles souffrent de mauvaises performances dans une variété de scénarios - OLAP /ETL des produits existent pour combler ces lacunes.

Cela change lentement. Il existe des implémentations de logiciels commerciaux et libres/open source qui évitent enfin cet écueil fondamental :

Bien sûr, le point n'est pas qu'il doit exister une conception de stockage physique "optimale", mais que toute conception de stockage physique peut être abstraite par un joli langage déclaratif basé sur l'algèbre/les calculs relationnels (et SQL est un mauvais exemple) ou plus directement sur un langage de programmation logique (comme Prolog, par exemple - voir ma réponse à "convertisseur prolog en SQL " question). Un bon SGBD devrait modifier la conception du stockage physique à la volée, en fonction des statistiques d'accès aux données (et/ou des conseils de l'utilisateur).

Enfin, dans le commentaire d'Eggermont, la déclaration " Le modèle relationnel se coince entre le cloud et le prevayler. " est une autre absurdité mais je ne peux pas réfuter ici, ce commentaire est déjà trop long.