Discussion :

[Acquatella]

Bonjour à vous tous,

Je me posais une question au sujet de la conception d'une base de données : Une grosse table ou plusieurs petites ?

J'ai pu lire qu'il fallait privilégier "plusieurs petites"...

Pour une table "produits" il peut y avoir ces champs :

nom_produit, référence, slug, titre, ...etc et aussi un nombre "X" de critères (Critère N°1, Critère N° 2, ... etc.)
Et un nombre "X" d'autres choses...

Alors comment "voir" la chose :

Un nouvelle table (critères) avec des champs :
id, id produit, critère 1, critère 2, critère 3, etc... (Autant de champ qu'il y a de critère !?)

Puis une autre table "Autres choses" ... (Avec autant de champ qu'il y a "d'Autres choses" !?)

Ou :

id, id produit, "cle", "valeur"
Et ainsi :
1 | 1 | critère 1 | Rouge
2 | 1 | critère 2 | Plastique
3 | 1 | critère 3 | 100g
4 | 2 | critère 1 | Vert
5 | 2 | critère 2 | Bois
6 | 2 | critère 3 | 500g
...

Et pourquoi pas mettre aussi dans cette même table : les "Autres choses" au lieu de créer une nouvelle table : "Autres choses" ?

id, id produit, "cle", "valeur"
100 | 1 | prix 1 | 5.75
101 | 1 | prix 2 | 5.00
102 | 1 | prix 3 | 4.75

Dans l'absolu si ce modèle de conception est ok, je pourrais créer dans une nouvelle table "Specs" (spécificités) le libellé de toutes les spécificités d'un produit.

Ainsi dans ma table specs

id , parent, nom , ...
1 | 0 | Produits
2 | 1 | couleur
3 | 1 | matière
4 | 1 | poids
5 | 1 | prix 1
6 | 1 | prix 2
7 | 1 | prix 3

Et ainsi si je dois en ajouter par la suite (imaginons qu'un nouveau prix arrive ou critères), je pourrais le faire simplement :

id , parent, nom , ...
3251 | 1 | prix 4

Qu'en pensez vous ?
Est ce envisageable ?
Ai-je été clair ?

Merci de votre aide et temps.

[SQLpro]

C'est une manière particulièrement stupide de modéliser une base. En effet il suffit d'imagine les requêtes du style, trouvez tous les zigzornifle rouge d'un poids inférieur à 2 tonnes, d'un prix de moins de 500 € en métal avec une poignée....
Votre requête finale devra lire 5 fois successivement la table
Je vous convie à suivre un cours de modélisation de données et revoir vos cours sur le sujet !
A défaut, lire au moins le livre que nous avons écrit Christian et moi :


A +

[Acquatella]

Merci de votre réponse SQLpro,

C'était une question (C'est charmant ici !)

Que se passe t'il si un nouveau critère devait être ajouté. (Un quatrième "prix" par ex.) ?

Il faudrait donc ajouter un nouveau champ dans la table ?

Merci

[escartefigue]

Bonjour,

Puisque vous avez des critères de nature différente, vous devez modéliser une entité-type "type de critère" (id, code type, libellé du type, date de début de validité...)
Puis vous établirez un modèle comme suit :

PRODUIT 1,n --- posseder --- 0,n CRITERE 1,1 --- typer --- 0,n TYPE DE CRITERE

[Acquatella]

Bonjour et merci escartefigue de votre réponse.

Je ne suis pas sur d'avoir compris...

Ce que j'ai cru comprendre : en gros créer une table : "Type de critères" (Avec : "Critere1", "Critere2", .... , "Prix1", "Prix2", ... etc.)
Qui détaillerait tous les critères des produits.

La table "Produits",...

Et une nouvelle table de liaison : "Critères" qui elle aura les "relations" entre le deux tables.

Alors si je comprend bien (déjà Si j'ai bien compris !), la problématique que décrivait "SQLpro" :

"Votre requête finale devra lire 5 fois successivement la table..."

se retrouvera ici ?

Parce qu'il me semble (Encore une fois , si j'ai bien compris), que c'est ce que je décrivais dans mon premier poste :

Ainsi dans ma table specs

id , parent, nom , ...
1 | 0 | Produits
2 | 1 | couleur
3 | 1 | matière
4 | 1 | poids
5 | 1 | prix 1
6 | 1 | prix 2
7 | 1 | prix 3

Ou ma table "specs" liste les types de critères qu'un produit peu avoir. (Avec la relation "parent")

Et la table "CRITERE" que je décrivais (ma table de liaison) :

id, id produit, "cle", "valeur"
Et ainsi :
1 | 1 | critère 1 | Rouge
2 | 1 | critère 2 | Plastique
3 | 1 | critère 3 | 100g
4 | 2 | critère 1 | Vert
5 | 2 | critère 2 | Bois
6 | 2 | critère 3 | 500g
...

Voilà ! Reste à savoir si j'ai bien compris votre message.

En tout cas merci de votre temps.

[SQLpro]

Les critères devraient être connus à l'avance. Dans les cas complexes on utilise la modélisation par héritage. Toute autre solution ne supportera pas une charge importante des requêtes des utilisateurs.

A +

[Acquatella]

SQLpro,

Merci de votre réponse.

Je ne connais pas "la modélisation par héritage" mais je vais essayer de glaner des informations sur Internet.

Merci à vous deux de votre temps et aide.

[SQLpro]

SQLpro,

Merci de votre réponse.

Je ne connais pas "la modélisation par héritage" mais je vais essayer de glaner des informations sur Internet.

Merci à vous deux de votre temps et aide.

Il suffit de lire les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/m...tion/heritage/

A +