0

Un produit peut avoir beaucoup de choses à dire à ce sujet, je les appellerai Propriétés. Il peut avoir une brève description. Mais cette description peut être dans plusieurs langues. De même, il peut avoir plusieurs prix, certains qui sont spécifiques aux clients. Étant donné les données suivantes:Y a-t-il un avantage à créer un modèle de données très générique pour un projet Rails 3?

Product: 
    identifier: 123-ABC 

    Price: 
    value: $1.25 
    currency: USD 
    customer: Wal-Mart 

    Price: 
    value: $1.96 
    currency: USD 

    Description: 
    short: "A Widget" 
    language: EN 

    Description: 
    marketing: "Made from Space Age Polymers." 
    language: EN 

Est-il judicieux d'utiliser STI ici et faire un ensemble générique de modèles:

Product has_many Properties 
Property has_many Attributes 

Price < Property 
Description < Property 
Package < Property 

Est-ce trop large d'une généralisation dans le modèle de données? Dois-je rester avec les modèles réguliers et leurs tables associées?

Répondre

3

n °

sérieusement

n °

au moins pas dans une base de données SQL.

Si vous voulez utiliser Cassandra ou une base de données NoSQL, c'est exactement comme cela que tout est stocké.

Read my answer here et Read this

Pensez d'une table SQL avec Prénom, Nom et date de naissance

Retrouvez toutes les LNAME = page de plus de 30

dans une table, il est

SELECT FNAME, LNAME, (SYSDATE - BDATE)/365 âge FROM personnes O LN LNAM E = 'Page' et bdate < SYSDATE - 30 * 365

essayer maintenant dans un EAV

Poster votre réponse.

+0

Je ne le ferai pas, mais je parie qu'il y aurait un EXISTS dedans. Je suppose qu'ils le feraient tous. Merci Steph ;-) – AKWF

+0

Mais voici mon vrai problème. Il y a BEAUCOUP d'attributs de produits potentiels qui sont composés dans la nature. Comme une valeur associée à un language_code ou à un unit_of_measure. Il semble fou d'avoir chacun de ceux-ci comme leur propre modèle ou même comme attributs explicites. La norme de données que j'essaie de gérer a des attributs possibles, dont certains sont composés. Mais chaque produit ne "se soucie" que d'une cinquantaine de personnes. – AKWF

+0

AK, C'est un point très important ... SOINS, Attention à 50. Cela signifie que le filtre sur ou sur le groupe, etc. Premièrement, (je ne crois pas cela parce que je suis un toxicomane), mais pourquoi votre DB a données que personne ne se soucie. Oui, je le garderais. Et dans ces cas, vous devrez réfléchir à ce que vous allez en faire. Si vous le gardez juste pour le garder, mettez-le dans un CLOB ou un XMLType. Ensuite, lorsque le 51ème devient CARED, ajoutez cette colonne et effectuez une mise à jour de la colonne depuis le magasin XML. –