Structure en option sql

Question

monde

DB est pas à moi, alors peut-être la question est triviale

Imaginez la conception d'un DB qui stockent des données de différents types d'éléments (comme types de données)

Je ne sais pas comment je devrais faire , mais voilà comment je le fais

id | quantity | price ... Kind | ID_k_foreing | 

alors pour tout type d'articles serait une table avec des propriétés de chaque type

donc via le logiciel que je pourrais comparer le genre et faire le joint à la table appropriée

comme cette pseudo-code

switch(kind) 
{ 
case chess_game: 
     the join is made with a table like this: 
     id_k| material | length | weigth .. 
case car_toy: 
     the join is made with a table like this: 
     id_k| color | velocity | remote_control ... 
case doll: 
     the join is made with a table like this: 
     id_k| name | height | clothes .. 

... 

} 

Il y a une certaine façon standar pour résoudre ce problème « type de données » dans la structure sans ajout de fonctions logicielles difficiles?

grâce

Answer 1

Vous voudrez peut-être jeter un oeil à ce question.

Bill Karwin answer le répartit de cette façon.

Vous avez au moins ces cinq options pour modéliser la hiérarchie de type que vous décrivent:

Single Table héritage: une table pour tous les types de produits, avec assez colonnes pour stocker tous les attributs de tous types . Cela signifie beaucoup de colonnes, dont la plupart sont NULL sur une ligne donnée.

Class Table Inheritance: une table pour Produits, attributs de stockage communs à tous les types de produits. Puis une table par type de produit , stockant les attributs spécifiques à ce type de produit.

Concrete Table Inheritance: pas de table pour les attributs communs des produits. Au lieu de cela, une table par type de produit, stockant à la fois les attributs communs et les attributs spécifiques au produit.

Serialized LOB: Une table pour Produits, stockant les attributs communs à tous les types de produits. Une colonne supplémentaire stocke un BLOB de données semi-structurées, en XML, YAML, JSON ou un autre format . Ce BLOB vous permet de stocker les attributs spécifiques à chaque type de produit . Vous pouvez utiliser les motifs fantaisie pour décrire cela, par exemple Façade et Memento. Mais indépendamment de vous avoir un blob d'attributs qui ne peuvent pas être facilement interrogé dans SQL; vous avez pour ramener le blob entier à l'application et le trier là-bas.

Entity-Attribute-Value: Une table pour produits, et une table qui pivote attributs aux lignes, au lieu de colonnes. EAV n'est pas un design valide par rapport au paradigme relationnel , mais de nombreuses personnes l'utilisent de toute façon . C'est le "Properties Pattern" mentionné par une autre réponse. Voir les autres questions avec l'étiquette eav sur StackOverflow pour certains des pièges .

Vous devrez trier celui qui fonctionne pour vous.