Schema : Segmentation des données !
Le
Etienne Sobole

Salut.
J'ai une base de donnée de produit.
aujourd'hui je dois ajouter des attributs qui permettent de segmenter ces p=
roduits.
Le problème est qu'en fonction des produits, les attribut ne vont pas ê=
tre les mêmes.
Par exemple (en simplifiant):
Pour une cartouche d'encre je vais avoir la capacité, la couleur et le vo=
lume
Pour un CD, je vais avoir la capacité, la vitesse de lecture, et le mode =
(+R -R, )
Donc, j'ai plusieurs options !
1 - ajoute a ma table produit les colonnes capacité, couleur, volume, vit=
esse et mode. C'est simple, mais je vais avoir des tas de colonnes qui ne s=
ervent a rien pour certains type de produit
2 - je créer une table attribut contenant une entrée pour chaque attrib=
ut. Ca donne une truc genre
CREATE TABLE "product_attribut" (
"idproduct" integer,
"attribut" text,
"value" text,
PRIMARY key (idproduit, attribut),
FOREIGN key (idproduct) REFERENCES product (idproduct)
);
Pourquoi pas !!!
Je suis pas fan, ca risque de mouler un peu lors des jointures !!!
3 - j'utilise l'héritage
Je crée alors une table
product_cd pour les CD
product_je pour les cartouche jet d'encre
Le probleme est alors d'arriver a transformer un enregistrement de type pro=
duc en product_cd. Je pense meme que c'est carrément pas possible.
Bref.
Pour quelle solution faut-il que j'opte ?
Une idée ?
Un retour d'expérience ?
Merci,
Etienne.
J'ai une base de donnée de produit.
aujourd'hui je dois ajouter des attributs qui permettent de segmenter ces p=
roduits.
Le problème est qu'en fonction des produits, les attribut ne vont pas ê=
tre les mêmes.
Par exemple (en simplifiant):
Pour une cartouche d'encre je vais avoir la capacité, la couleur et le vo=
lume
Pour un CD, je vais avoir la capacité, la vitesse de lecture, et le mode =
(+R -R, )
Donc, j'ai plusieurs options !
1 - ajoute a ma table produit les colonnes capacité, couleur, volume, vit=
esse et mode. C'est simple, mais je vais avoir des tas de colonnes qui ne s=
ervent a rien pour certains type de produit
2 - je créer une table attribut contenant une entrée pour chaque attrib=
ut. Ca donne une truc genre
CREATE TABLE "product_attribut" (
"idproduct" integer,
"attribut" text,
"value" text,
PRIMARY key (idproduit, attribut),
FOREIGN key (idproduct) REFERENCES product (idproduct)
);
Pourquoi pas !!!
Je suis pas fan, ca risque de mouler un peu lors des jointures !!!
3 - j'utilise l'héritage
Je crée alors une table
product_cd pour les CD
product_je pour les cartouche jet d'encre
Le probleme est alors d'arriver a transformer un enregistrement de type pro=
duc en product_cd. Je pense meme que c'est carrément pas possible.
Bref.
Pour quelle solution faut-il que j'opte ?
Une idée ?
Un retour d'expérience ?
Merci,
Etienne.
Le 11/03/2013 12:00, Etienne Sobole a écrit :
ces produits.
être les mêmes.
le volume
mode (+R -R, ...)
vitesse et mode. C'est simple, mais je vais avoir des tas de colonnes
qui ne servent a rien pour certains type de produit
MAUVAIS : par principe pas de NULL !
attribut. Ca donne une truc genre
C'est bien si très peu d'interrogations...
oui, largement préférable
non,
- product_encre
-- product_encre_solide (toner)
-- product_encre_liquide
etc...
héritage à plusieurs niveaux...
type produc en product_cd. Je pense meme que c'est carrément pas possible.
Il suffit d'utiliser des déclencheur INTEAD OF et des vues.
Lisez les articles que j'ai écrit à ce sujet...
http://sqlpro.developpez.com/cours/modelisation/heritage/
http://blog.developpez.com/sqlpro/p9259/ms-sql-server/exemple_d_utilisation_du_mapping_ro_dire
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************