Conception de database de produits

Je suis en train de concevoir une database à partir de produits manufacturés. La design de la key est la suivante: (Actuellement, je travaille sur MS Access 2007 mais ma dernière implémentation est SQL Server, SQL Server 2008 étant la dernière version et je n'utiliserais que l'édition Express pour ce mouvement. NET storefront interfacé avec cette database)

[1] .Chaque produit peut être divisé en plusieurs catégories. (J'ai décidé de supposer que si un produit n'a pas de catégorie, j'insertai forcément une catégorie appelée par le nom 'BLANK', plutôt que de l'appeler NULL, de cette façon je pourrai append des catégories au produit si nécessaire ) 1 Le produit peut avoir plusieurs catégories. 1 Catégorie peut appartenir à plus de 1 produits. Les catégories peuvent également être modifiées pour appartenir à un produit différent à l'avenir.

[2] .Chaque catégorie de produits peut être divisée en plusieurs sous-catégories. (Encore une fois, j'ai décidé de supposer que si une catégorie de produit n'a pas de sous-catégorie, j'insertai avec force une sous-catégorie appelée 'BLANK' plutôt que de l'appeler NULL, de cette façon je peux append des sous-catégories à une catégorie de produit à l'avenir si nécessaire) 1 La catégorie de produit peut comporter plusieurs sous-catégories. 1 Sous-catégorie peut appartenir à plus de 1 catégorie de produit. Les sous-catégories peuvent également être modifiées pour appartenir à une catégorie de produit différente à l'avenir.

[3] .Chaque produit aura un nombre différent d'attributes. Chaque atsortingbut aura des valeurs d'atsortingbut différentes Les valeurs de certains attributes dépendront des valeurs d'autres attributes Les valeurs de certains attributes qui ne dépendent pas directement de la valeur d'autres attributes dépendront encore indirectement de la disponibilité des valeurs d'autres attributes. les attributes.

Le dessin que j'ai développé est le suivant:

0000_Product_Line
ProductLineID (PK)
ProductLineName

0001_Product_Line_Category
ProductLineCategoryID (PK)
ProductLineCategoryName

0002_Product_Line_Category_Association
[PK] ProductLineID (FK Referring ProductLineID de la table 0000_Product_Line)
[PK] ProductLineCategoryID (FK Référence ProductLineCategoryID de la table 0001_Product_Line_Category)

0003_Product_Line_Sub_Category
ProductLineSubCategoryID (PK)
ProductLineSubCategoryName

0004_Product_Line_Category_And_Sub_Category_Association
[PK] ProductLineCategoryID (FK Référence ProductLineCategoryID de la table 0001_Product_Line_Category)
[PK] ProductLineSubCategoryID (FK référençant ProductLineSubCategoryID de la table 0003_Product_Line_Sub_Category)

0005_Product_Line_Atsortingbutes
AtsortingbuteID (PK)
Nom d'atsortingbut

0006_Product_Line_Atsortingbute_Values
[PK] AtsortingbuteID (FK AtsortingbuteID AtsortingbuteID de la table 0005_Product_Line_Atsortingbutes)
[PK] AtsortingbuteValues

0007_Product_Line_Atsortingbutes_Association
[PK] ProductLineSubCategoryID (FK référençant ProductLineSubCategoryID de la table 0003_Product_Line_Sub_Category)
[PK] AtsortingbuteID (FK AtsortingbuteID AtsortingbuteID de la table 0005_Product_Line_Atsortingbutes)

Maintenant, les plus gros problèmes sont comment gérer les attributes de différents produits (enfin les sous-catégories de produits, car je mets tout en sous-catégories de produits car même si un produit a ou non une catégorie ou une sous-catégorie, j'insertai forcément un BLANK catégorie et sous-catégorie)

Supposons que j'ai les valeurs suivantes:

Gamme de produits:
UNE
B

Catégories de la gamme de produits
A A1
A A2
Un A3
B B1
B B2

Gamme de produits Sous Catégories
A A1 a
A A1 b
A A1 c
A A2 x
A A2 y
B B1 m
B B1 n
B B2 p
B B2 q
B B2 r

Les attributes
un att1
un att2
un att3
b att2
b att4
c att1
c att3
c att4
x att2
x att3
y att4
y att5
m att3
m att7
n att1
n att7
p att2
p att3
p att5
q att4
q att6
r att1
Att6

Valeurs d'atsortingbut
att1 Valeur1
att1 Valeur2
att1 Value3
att2 Value1
att2 Value2
att2 Value3
att2 Value4
att3 Value1
att3 Value2
att4 Value1
att4 Value2
att4 Value3
att4 Value4
att4 Value5
……

Maintenant par exemple: att1 et att2 sont liés Donc si l'user sélectionne une valeur pour att1, il détermine ce que toutes les valeurs de att2 doivent être mises à la disposition de l'user De même si l'user sélectionne Valeur pour att2, détermine toutes les valeurs de att3 disponible pour l'user

Il n'y a pas de hiérarchie qui, si att1 et att2 sont liés, l'user devrait choisir att1 premier et att2 suivant OU viceversa L'user peut sélectionner la valeur pour att1 ou att2 et il devrait filterr l'autre

Un autre exemple: att2 et att3 et att4 sont liés Donc si l'user sélectionne une valeur pour att2, il déterminera quelles sont les valeurs pour att3 et att4 qui devraient être mises à la disposition de l'user. De même, si l'user sélectionne une valeur pour att3, il déterminera quelles sont les valeurs de att2 et att4 qui doivent être mises à la disposition de l'user. De même, si l'user sélectionne une valeur pour att4, il déterminera quelles sont les valeurs de att2 et att3 qui doivent être mises à la disposition de l'user.

Ici aussi, il n'y a pas de hiérarchie qui, si att2 et att3 et att4 sont liés, l'user devrait sélectionner att2 premier et att3 suivant et att4 suivant OU viceversa L'user peut sélectionner la valeur pour att2 ou att3 ou att4 et il devrait filterr l'autre attributes associés

Comment puis-je établir une relation entre différents attributes afin que mon filter utilisant la clause where fonctionne correctement? Si elles étaient toutes des colonnes, je pourrais facilement utiliser group by, mais ce sont des lignes.

J'ai fait beaucoup de search sur internet et suis venu avec les options suivantes: 1. Utilisez une grande table pour tous les produits et leurs attributes. Mais la taille de cette table sera immensément énorme avec d'innombrables valeurs nulles dans diverses colonnes et il ne servira pas le server comme la lecture en utilisant des sélections aurait une incidence énorme sur les performances.

Utilisez des colonnes Sparse dans SQL Server 2008 pour éviter les effets de valeurs null. Cependant, même si les colonnes éparses sauvegardent de l'espace pour les valeurs nulles, elles nécessitent un espace de stockage supérieur à la normale pour les valeurs qui ne sont pas nulles. la taille de la table est encore énorme avec d'innombrables colonnes affectant les performances de lecture.
Je devrais utiliser XML pour stocker des données. Je ne suis pas sûr de la façon dont je le mettrais en œuvre et quels seraient les avantages ou les inconvénients.
Je devrais le décomposer en petites tables séparées pour chaque sous-catégorie représentant seulement ses propres attributes en tant que colonnes plutôt que celui de l'set du produit ou de sa catégorie. Ensuite, je passerais le nom de la table en tant que parameters dans mon code d'application. Cependant, cela aura le problème de l'injection SQL. La résolution consisterait à utiliser la procédure stockée avec des requêtes paramétrées. Cependant, les performances seront toujours affectées car le moteur de database ne peut pas optimiser les plans de requête pour ces requêtes où les jointures sont effectuées uniquement pour atteindre une sous-catégorie, mais après un nom de table est appelé par un paramètre passant la sous-catégorie.
Je devrais écrire des requêtes SQL pour préparer une vue de chaque sous-catégorie représentant ses propres attributes (plutôt que d'avoir une table séparée pour chaque sous-catégorie). Cependant, pour créer des vues, il faudrait que les relations soient stockées quelque part parce que certains attributes dépendent les uns des autres directement en fonction des valeurs et que certains attributes dépendent l'un de l'autre indirectement en fonction de l'avilabilité des valeurs. Donc, je vais avoir cette table d'attributes et de valeurs (comme je l'ai déjà conçu) et puis j'ai besoin d'une table de relation récursive de plusieurs à plusieurs. Mais cette table de relation récursive à beaucoup à beaucoup sera immensément énorme et le nombre d'auto-jointures qui auront lieu affectera considérablement la performance. De plus, le nom de vue devra être passé en tant que paramètre à une procédure SQL dynamic ou à une procédure stockée paramétrée.
La dernière option que j'ai trouvée était la design de database EAV qui a ses propres avantages et inconvénients, y compris l'écriture de requêtes complexes ainsi que la surveillance des performances, car le moteur de database ne peut pas optimiser les plans de requête pour une telle database. De plus, une telle database EAV perd la plus grande partie de son essence relationnelle et les contraintes sur les différentes valeurs sont très difficiles à appliquer, ce qui impliquera beaucoup de triggersurs.

Je ne suis pas sûr de ce qui serait la meilleure option pour concevoir ma database. La database serait principalement accessible sur les requêtes SELECT via l'application. Toute insertion pour un produit ou sa catégorie ou sous-catégorie ou ses attributes ou valeurs sera effectuée par saisie de données. (Les insertions directes seront effectuées pour l'logging des fournisseurs / fabricants de produits et de clients, ce que je suppose être une database distincte pour le moment. fabrication) Les users pourront filterr vers une sous-catégorie, sélectionner ses valeurs d'atsortingbut et acheter le produit en ligne. Il y a aussi un besoin pour un filter (par filter, c'est-à-dire des requêtes utilisant la clause where) requirejs lorsque l'user ne saura pas quel type de produit il veut, donc il sélectionnera les attributes qu'il veut filterr et il doit correspondre à un des sous-catégories et enfin l'user devrait être en mesure de sélectionner les valeurs pour les attributes.

Je suis vraiment confus avec la façon dont je mets en œuvre ma database et face à de nombreux défis étant seul dans l'équipe informatique dans une petite entreprise.

Toute aide de votre part sera grandement appréciée et considérée comme un atout énorme.

Avez-vous cependant à propos d'avoir une table avec une relation parent / enfant. (Table auto-référencée). Initialement en regardant vos tables, cela fonctionnerait jusqu'à la table Atsortingbuts.

par exemple structure de table (3 colonnes)

ID Nom ParentID
0 A NULL
1 B NULL
2 A1 0
3 A2 0
4 B1 1
5 B2 1
6 a 2
7 b 2
8 x 4
9 att1 6
10 att2 6
11 att2 8
12 att3 8

Vous pouvez travailler sur la structure de la hiérarchie en vous auto-joignant à la table en utilisant le parentID pour get le groupe parent.

Les deux premières inputs de l'exemple proviennent de la table Product Line. Ils n'ont pas de ParentID
Les 4 inputs suivantes (A1, A2, B1, B2) proviennent du tableau Catégories de lignes de produits, avec un parentID pour renvoyer aux données de ligne de produit (A, B)
Ensuite, les trois inputs suivantes proviennent du tableau des sous-catégories de la ligne de produits. Notez à nouveau comment ParentID reference l'ID pour (A1, A2, B1, B2). Les 4 attributes finaux referencent datatables dans le tableau des sous-catégories de lignes de produits.

Avec cette méthode, vous pouvez coller toutes les informations requirejses dans une table, ce qui signifie également que vous avez des colonnes nulles car vous ne stockez que datatables requirejses

NOTE: La partie key à comprendre est la 3ème colonne ParentID qui stocke la reference à la table parent dans votre design actuel