Discussion :

[Sinbad93]

Bonjour,
J'ai une base donnée avec une table qui contient les informations d'un produit, ce produit peut se situer dans l'entrepôt A ou B.
Côte utilisateur je choisis mon entrepôt avant d'afficher les produits. Côté Admin je veux avoir un visu total des produits ou pouvoir scinder par entrepôt.
Ma question concerne l'agencement des tables pour la performance des requêtes.
Je ne sais pas si il est préférable de :
Mettre tous les produits dans la même table avec un ENUM pour déterminer l'entrepôt et donc des requêtes WHERE Entrepot = A ou B pour afficher mes produit
OU
Faire un table par entrepôt ce qui permet de diviser par deux le nombre de lignes de produits et donc des requêtes SELECT * plus rapide que Where
Dans ce cas l'admin doit requêter 2 table différentes pour avoir tout ses produits
Question :
Est ce que 2: SELECT * sans Where valent mieux qu'un SELECT qu'avec un WHERE ? et dans quelle mesure car il faut voir qu'une architecture avec un ENUM est moins chronophage à coder et à gérer que deux tables séparés.

Merci de votre attention, je suis un développeur junior et je souhaite avoir les bonnes pratiques pour que mes requêtes soient toujours performantes quelque soit le volume.

[tatayo]

Bonjour,
Si tu pars sur une table "produit" par entrepôt, tu vas vite galérer quand tu vas ajouter des entrepôts... Si tu veux tout voir, il faudra faire des unions en cascade, et modifier la requête à chaque ajout d'un entrepôt.
Pour ma part, je partirai sur 3 tables:

1. Une table Produit
2. Une table Entrepôt
3. Une table croisée entre les deux (Produit_Entrepôt)

La table Produit_Entrepôt possède, en plus des clés primaire des tables Produit et Entrepôt (avec une contrainte d'unicité sur le couple), des données comme par exemple le stock, la dernière date d'entrée...

Ainsi tu peux ajouter autant d'entrepôts que nécessaire, mettre un même produit dans deux entrepôts...

Tatayo.

[escartefigue]

Bonjour,

Le découpage en tables, au moins dans un premier temps, ne doit pas être le résultat de considérations techniques (les perfs, la façon de construire les requêtes ou autres), mais seulement de la réalité des règles de gestion.
Si un même produit peut être dans plusieurs entrepôts alors il faut à minima deux tables.
Mais, le plus souvent, on gère également la localisation des produits dans les entrepôts, ne serait-ce que pour ne pas avoir à chercher dans tout l'entrepot où est stocké le produit et également pour ne pas chercher à ranger un produit dans un endroit de l'entrepôt déjà occupé.
Pour ce faire, la plupart des logiciels de gestion de stock prévoient une gestion par entrepot, magasin, emplacement.

Ainsi on aura un modèle conceptuel du type :
[PRODUIT] 0,n --- stocker --- 0,1 [EMPLACEMENT] 1,1(R) --- localiser --- 1,n [MAGASIN] 1,1(R) --- situer --- 1,n[ENTREPOT]

Ce qui donne 4 tables
L'identification relative notée x,y(R) permettra justement d'optimiser les recherches

[Sinbad93]

Merci pour votre aide à tous les deux,
c'est très clair, même si le sujet de la vitesse n'est pas abordé,
les conseils au niveau de l'architecture sont précieux.
Bon code à tous !

[SQLpro]

En particulier les types non atomique comme ENUM ou ARRAY, ne devraient JAMAIS être utilisés. Ce sont des types non relationnels impossible à indexer !
Leur usage doit être réservé aux routines (Procédure stockées, Fonction UDF...) mais jamais à la construction des tables.

Enfin, les performances se gèrent par les actions de DBA au niveau physique et non au niveau de la conception du modèle qui doit être normalisé (voir : https://fsmrel.developpez.com/basesr...normalisation/)

Un modèle parfaitement normalisé est facile à rendre performant par l'ajout d'index.

Un modèle dénormalisé est difficile à rendre performant, voire impossible (exemple : tables obèses, utilisation de types non atomiques comme ARRAY ou ENUM...).

A +