2009-08-25 7 views
0

Désolé pour le mauvais titre, mais je n'ai aucune idée de comment mettre cela en bref. Le problème est le suivant:Avoir un comportement de type instance dans les bases de données

J'ai un élément générique qui représente un groupe, appelons-le Car. Maintenant, ce Car a des attributs, qui vont dans certaines limites, disons par exemple la vitesse est comprise entre 0 et 180 pour un voiture d'habitude. Imaginez quelques autres attributs avec des plages ici, par exemple Couleur est entre 0 et 255 quelle que soit cette valeur.

Donc, dans ma table GenericItems J'ai:

ID Name 

1 Car 

Et dans mon Attributs Je:

ID Name Min_Value Max Value 
1 Speed  0   180 
2 Color  0   255 

La relation entre la voiture et les attributs est donc 1: n.

Maintenant, je commence à avoir des instances très spécifiques de mon Car par exemple un FordMustang, un FerrariF40, et un DodgeViper. Ce sont des instances spécifiques et maintenant je veux leur donner des valeurs spécifiques pour leurs attributs.

Donc, dans ma table SpecificItem J'ai:

ID Name   GenericItem_ID 

1 FordMustang   1 
2 DodgeViper   1 
3 FerrariF40   1 

Maintenant, je besoin d'une troisième table SpecificAttributes2SpecificItems, pour correspondre à des attributs à SpecificItems:

ID SpecificItem_ID Attribute_ID Value 

1   1    1   120  ;Ford Mustang goes 120 only 
2   1    2   123  ;Ford Mustang is red 
3   2    1   150  ;Dodge Viper goes 150 
4   2    2   255  ;Dodge Viper is white 
5   3    1   180  ;FerrariF40 goes 180 
6   3    2    0  ;FerrariF40 is black 

Le problème avec cette le design est, comme vous pouvez le voir, que je copie toujours sur toutes les lignes d'attributs, et je me sens comme C'est un mauvais design, inconsistant, etc. Comment puis-je atteindre cette logique d'une manière correcte et normalisée?

Je veux être en mesure d'avoir plusieurs éléments génériques, avec plusieurs attributs avec des valeurs min/max comme intervalle, qui peut être « instanciées » avec des valeurs spécifiques

Répondre

1

Il semble que vous essayez de répliquer Entity Atribute Value comme un design, ce qui conduit à beaucoup de tables laides (enfin, il s'agit généralement d'une seule table pour tout).

http://en.wikipedia.org/wiki/Entity-attribute-value_model http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm

Discutant EAV a tendance à conduire à « guerres de religion », comme il y a très peu de bons endroits pour l'utiliser (beaucoup de gens disent qu'il ya zéro bons endroits) et il y a d'autres gens qui pensent que, depuis il est tellement flexible qu'il devrait être utilisé partout. Si je peux trouver la référence que je cherche, je l'ajouterai à ceci.

1

La meilleure façon d'utiliser l'héritage dans les modèles de base de données est de utilisez un outil ORM. Pour Python il y a SQLAlchemy, Django et autres.

Maintenant, vous devriez vous demander si, par ex. une Ford Mustang est une sorte de voiture, ou une instance de voiture. Dans le premier cas, vous devez créer une table ford_mustang définissant les attributs ford_mustang. La table ford_mustang devrait alors également avoir une clé étrangère à la table car, où les attributs génériques de chaque FordMustang sont spécifiés. Dans ce dernier cas, chaque type de voiture est juste une rangée dans la table Car. De toute façon, chaque attribut doit être représenté dans une seule colonne.

La validation des attributs est généralement effectuée dans la logique métier de l'application.

1

Il existe une école de pensée selon laquelle toute tentative de construire un modèle EAV dans un SGBDR constitue un «mauvais design», mais nous n'irons pas là-bas. Oups, on dirait que quelqu'un d'autre a déjà fait.

Je ne suis pas certain de ce qui vous inquiète. SpecificAttributes2SpecificItems est une table d'intersection (l'indice se trouve dans le nom). Nécessairement, il comprend des liens vers les attributs et SpecificItems. Comment cela pourrait-il pas?

Vous devez probablement avoir un MinVal et un MaxVal sur SpecificAttributes2SpecificItems, que certains éléments auront une gamme plus limitée que celle permise par les GenericItems. Par exemple, tout le monde sait que Ferraris devrait seulement être disponible en rouge.

+0

upvote pour être drôle;) Ce qui me préoccupe est que ma conception se sent tout simplement faux. Quand j'écris mes inserts ... en faisant défiler tous les attributs "template", et en les copiant dans ma table d'intersection, en les spécialisant avec une valeur. J'ai l'impression de simuler quelque chose ici, qui devrait être amélioré. – Tom

1

Couple d'idées:

Tout d'abord, vous devriez envisager de faire votre table « genericgroups » un « attribut » plutôt que quelque chose en vol stationnaire au-dessus du reste des données. Deuxièmement, vous pouvez avoir plus de facilité à faire en sorte que chaque table attributaire conserve les attributs des éléments, pas simplement l'idée des attributs. Si vous voulez avoir une plage, considérons soit un type enum (pour les noms d'éléments) ou simplement un entier avec un maximum défini (ainsi la valeur de la colonne color_value ne peut pas être supérieure à 255). De cette façon, vous finirez avec quelque chose comme:

Item Table 
    ID Name 

    1 FordMustang 
    2 DodgeViper 
    3 FerrariF40 

    ItemType Table: 

    ItemID  Type 
    1   Car 
    2   Car 
    3   Car 


    ItemColor Table: 

    ItemID  ColorID 
    1   123 
    2   255 
    3   0 

    MaxSpeed Table 

    ItemID  MaxSpeedID 

    1  120 
    2  150 
    3  180 
+0

Impossible. La première chose est, j'ai environ 300 attributs différents, et ils doivent être dynamiquement extensibles, sans pirater la mise en page de la base de données. tout devrait être fait par CRUD sur les tables existantes. La deuxième chose est que non seulement les voitures, mais aussi les maisons, les avions, etc. doivent être modélisés. Je veux prendre un objet totalement arbitraire, lui inventer des attributs et des gammes d'attributs, puis spécifier des instances de cet objet, avec des valeurs spécifiques pour les attributs. – Tom

+0

Considérons donc une base de données tout à fait différente au lieu de SQL, comme CouchDB ou MongoDB. Les DB orientés document peuvent stocker des données en tant que documents JSON, ce qui ressemble davantage à ce que vous décrivez. – Anthony

Questions connexes