comment stocker des données avec de nombreuses catégories et de nombreuses propriétés efficacement?

Question

Nous avons un grand nombre de données dans de nombreuses catégories avec de nombreuses propriétés, par ex.

category 1: Book 

properties: BookID, BookName, BookType, BookAuthor, BookPrice 

category 2: Fruit 

properties: FruitID, FruitName, FruitShape, FruitColor, FruitPrice 

Nous avons beaucoup de catégories comme livre et fruit. Évidemment nous pouvons créer beaucoup de tables pour eux (MySQL par exemple), et chaque catégorie une table. Mais cela va créer trop de tables et nous devons écrire de nombreux "adaptateurs" pour unifier les données manipulées.

Les difficultés sont:

1) Chaque catégorie a des propriétés différentes et cela se traduit par une structure de données différentes.

2) Les propriétés de chaque catégorie peuvent devoir être modifiées à tout moment.

3) Difficile à manipuler des données si chaque catégorie une table (trop de tables)

Comment conserver ce genre de données?

Answer 1

Vous pouvez séparer la base de données en deux parties: les tables de définition et les tables de données. Fondamentalement les tables de définition sont utilisées pour interpréter les tables de données où les données réelles sont stockées (certains diraient que les tables de définition sont plus élégantes si elles sont représentées en XML).

Ce qui suit est l'idée de base.

Tables Définition:

TABLE class 
class_id (int) 
class_name (varchar) 

TABLE class_property 
property_id (int) 
class_id (int) 
property_name (varchar) 
property_type (varchar) 

Tableaux de données:

TABLE object 
object_id (int) 
class_id (varchar) 

TABLE object_property 
property_id (int) 
property_value (varchar) 

Il serait mieux si vous pouvez également créer couche supplémentaire pour interpréter la structure de manière à le rendre plus facile pour la couche de données pour fonctionner sur les données. Et vous devez bien sûr prendre en considération la performance, la facilité d'interrogation, etc.

Juste mes deux cents, j'espère que cela pourrait être de toute aide.

Cordialement.

Answer 2

Si votre collection de données n'est pas trop grande, le modèle Entity-Attribute-Value (EAV) peut parfaitement s'adapter à la facture.

En un mot, cette structure permet la définition de Catégories, la liste des [requis ou facultatif] Attributs (aka propriétés) les entités dans cette catégorie comprennent etc, dans une série de tableaux connu comme le méta-données, le schéma logique des données, si vous voulez. Les instances d'entité sont stockées dans deux tables, un en-tête et une table de valeurs, chaque attribut étant stocké dans un seul enregistrement [SQL] de la dernière table (alias stockage "vertical": ce qui était un enregistrement dans un modèle de SGBD traditionnel est fait de plusieurs enregistrements de la table de valeur).

Ce format est très pratique notamment pour sa flexibilité: il permet à la fois des changements tardifs et continus dans le schéma logique (ajout de nouvelles catégories, ajouts/changements dans les attributs d'une catégorie donnée etc.), ainsi que la gestion implicite par les données du schéma logique du catalogue sous-jacent, au niveau de l'application. Les principaux inconvénients de ce format sont l'implémentation [un peu] plus sophistiquée, abstraite, et surtout, certaines limitations concernant la mise à l'échelle, etc., lorsque la taille du catalogue augmente, disons dans la gamme million + d'entités.

Voir le modèle EAV décrit plus en détails dans this SO answer of mine.

Answer 3

Déclenché par cette question et d'autres similaires, j'ai écrit un blog post sur la façon de gérer de tels cas en utilisant une base de données graphique. En bref, les bases de données de graphes n'ont pas le problème "comment forcer une arborescence/hiérarchie dans des tables" car il n'y en a tout simplement pas besoin: vous stockez votre structure arborescente telle quelle. Ils ne sont pas bons pour tout (comme par exemple la création de rapports) mais c'est un cas où les bases de données graphiques brillent.