Modèle de base de données et performances

Question

J'utilise un modèle de base de données auto-construit. Ce modèle est construit pour une application de boutique en ligne. voici à quoi cela ressemble:

Tout d'abord j'ai une table pour mes produits. Ce ne contient que des données générales comme id et articlenr, pour tous les attributs des produits (comme le nom, le prix, etc) J'ai fait des tables séparées par type, donc je les tableaux suivants:

product_att_varchar 
product_att_decimal 
product_att_int 
product_att_select 
product_att_text 
product_att_date 

ces tables sont liées par une table relationnelle procuct_att_relational

Mon problème est la performance de cette structure, si je veux tous les attributs d'un produit spécifique si on doit utiliser autant de jointures que ça va beaucoup ralentir.

Est-ce que quelqu'un a une solution pour ça ???

Merci

Answer 1

Les gens reviennent toujours à ce modèle parce qu'ils pensent qu'il est "flexible". Eh bien, c'est ce que je suppose, mais cette flexibilité a un prix énorme: chaque mise à jour et chaque requête est lente et complexe. Quassnoi mentionne que si les attributs sont clairsemés, c'est-à-dire que la plupart des instances d'entités n'ont qu'un faible pourcentage des attributs possibles, ceci peut économiser de l'espace. C'est vrai, mais le revers de la médaille est que si elle n'est pas clairsemée, cela prend énormément plus d'espace, car maintenant vous devez stocker le nom ou le code d'attribut pour chaque attribut en plus de la valeur, plus vous devez répéter une sorte de clé pour identifier l'instance d'entité logique pour chaque attribut. Le seul moment auquel je peux penser lorsque ce serait une bonne idée est de savoir si la liste des attributs doit pouvoir être mise à jour à la volée, c'est-à-dire qu'un utilisateur doit pouvoir décider de créer un nouvel attribut chaque fois qu'il aime. Mais alors que va faire le système avec cet attribut? Si vous voulez juste que l'utilisateur soit en mesure de le saisir et ensuite récupérer ce qu'il a tapé, assez facile. Mais cela affectera-t-il le traitement de quelque façon que ce soit? Par exemple, si l'utilisateur décide d'ajouter un «code de vente en liquidation», comment votre programme saura-t-il comment cela affecte le prix de vente? Cela pourrait se faire bien sûr: vous pourriez avoir des écrans supplémentaires où l'utilisateur entre des données qui décrivent en quelque sorte comment chaque champ affecte le prix ou le réapprovisionnement ou quoi que ce soit. Mais cela ajouterait encore plus de couches de complexité.

Donc, ma réponse courte est: À moins que vous ayez une exigence très spécialisée, ne faites pas ceci. Si vous essayez de construire une base de données décrivant les articles que vous vendez, avec des choses comme la description et le prix et la quantité en main, alors créez une table avec des champs comme la description et le prix et la quantité en main. La vie est assez difficile sans sortir de votre chemin pour le rendre plus difficile.

Answer 2

Je ne vois aucune bonne raison de déplacer ces attributs de la table des produits. Ce serait une chose si vous le faisiez parce que vous aviez des données qui suggéraient un problème, mais on dirait que vous pensiez que «ce sera mieux». Pourquoi l'avez-vous fait de cette façon dès le départ?

Si vous l'aviez fait de cette façon parce qu'il a été généré pour vous, je vous recommande d'abandonner ce générateur.

Answer 3

Ce modèle est appelé EAV (entity-attribute-value) et présente ses inconvénients et ses avantages.

Les avantages sont que c'est très flexible et peut être étendu facilement. Cela peut être utile si vous avez un très grand nombre d'attributs très clairsemés, les attributs ne peuvent pas être prédits au moment du design (par exemple, fourni par l'utilisateur), ou les attributs qui sont rarement utilisés. Les inconvénients sont la performance et l'incapacité à indexer plusieurs attributs en même temps. Cependant, si votre système de base de données permet des vues indexées (comme SQL Server) ou le stockage en cluster de plusieurs tables (comme Oracle), les performances peuvent être améliorées en utilisant ces techniques. Cependant, stocker tous les attributs dans un enregistrement sera toujours plus rapide.