Comment structurer mes données ?

Comment structurer mes données ? - SQL/NoSQL - Programmation

Marsh Posté le 10-03-2007 à 13:08:43    

Bonjour
 
J'aurais besoin de quelques conseils quant à la structuration de la base de données, pour un site que j'aimerais réaliser.
 
Voilà le problème, pour résumer :
- différentes "stations de stockage", permettant de stocker plusieurs produits, le nombre de ces emplacements est amené à varier
- différents produits, chacun stockés dans une station de stockage, avec des caractéristiques : référence, marque, etc.
 
Je ne sais pas quelle solution adopter pour me permettre facilement de :
- (1) trouver tous les produits d'une certaine station de stockage
- (2) trouver toutes les stations de stockage contenant un produit de marque 'Machin'
- et autres, les deux points qui me semblent les plus importants étant les deux ci-dessus
 
J'ai pensé à faire un table par station de stockage, chaque enregistrement représentant un produit. Pratique il me semble pour la requête (1), mais beaucoup moins pour la requête (2) (je dis il me semble parce que je ne travaille pas souvent avec plusieurs tables, je ne sais pas s'il existe des mots-clés permettant facilement de rechercher dans toutes les tables dont le nom commence par 'truc', ou répondant à la condition Y).
 
J'ai pensé autrement à une table contenant tous les produits avec pour chaque enregistrement, entre autres, un champ indiquant dans quelle station de stockage il est situé, quitte à avoir des doublons si il y a des produits identiques dans différentes stations. Ca me semble assez pratique pour les requêtes (1) et (2) mais lorsque les produits seront nombreux, cela risque d'être lourd et peu optimisé à force non ?
 
Si vous pouvez me donner quelques conseils et/ou suggestions :)
 
Merci d'avance

Reply

Marsh Posté le 10-03-2007 à 13:08:43   

Reply

Marsh Posté le 11-03-2007 à 07:56:25    

Bonjour,
En plus de tes deux tables:
Une table "Entreposé dans" contenant un pointeur sur station de stockage et un sur produits.  
Si tu as beaucoup de Marques, une table Marques est la bienvenue
 Cordialement

Reply

Marsh Posté le 11-03-2007 à 11:08:56    

Bonjour, merci pour ta réponse :)
 
Le fait de dispatcher les informations dans plusieurs tables, et donc de devoir effectuer plus de requêtes que si les infos étaient regroupées, vaut-il mieux (au niveau rapidité d'exécution, utilisation des ressources, etC.) que d'effectuer une seule ou deux requêtes sur des grosses tables bourrées de colonnes diverses et variées ? (c'est juste une question parce que j'y connais pas grand chose en optimisation)
 
Pour la table Marques, tu veux dire une table sur le même principe que l'autre avec un pointeur sur station de stockage et un nom de marque ?
 
Merci d'avance

Reply

Marsh Posté le 11-03-2007 à 11:19:34    

Re,
voici un exemple, parmi beaucoup d'autres, qui peut t'aider à organiser tes bases de données
ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf
 
sinon attends lundi que les pros de la bdd actuelle complètent mes infos.
 

Citation :

Pour la table Marques, tu veux dire une table sur le même principe que l'autre avec un pointeur sur station de stockage et un nom de marque ?


 
pour l'instant, laisses tomber la table Marques si tu n'as pas trop de marques ni d'informations complémentaires liées aux marques (une "liste" te permettras d'avoir des saisies cohérentes , regardes déjà l'organisation de tes données. Evites les redondances inutiles.  
 
Cordialement


Message édité par seniorpapou le 11-03-2007 à 11:34:49
Reply

Marsh Posté le 11-03-2007 à 14:46:40    

Ok je vais regarder le PDF, et je verrai si d'autres personnes ont des conseils à donner.
 
Merci beaucoup pour ton aide :)

Reply

Marsh Posté le 12-03-2007 à 15:43:37    

tip of the day : c'est pas parce que t'as plus de tables que ça fait plus de requêtes hein :o y'a un truc qui s'appelle "jointures" et c'est là justement pour faire ça

Reply

Marsh Posté le 12-03-2007 à 21:12:36    

Je ne connaissais pas les jointures, merci du conseil j'ai pu me renseigner dessus.
 
En revanche je n'ai pas réussi à trouver si il existait un moyen d'effectuer un SELECT dans n tables de la base (n non constant bien sûr), en spécifiant une condition (genre nom de la table commence par 'stock' par exemple).. une idée ?
 
Merci

Reply

Marsh Posté le 13-03-2007 à 08:04:32    

non, c'est pas possible parceque ça sert à rien.
 
suis le lien qui est dans ma signature (2°) pour plus d'infos

Reply

Marsh Posté le 13-03-2007 à 15:18:32    

En revanche je n'ai pas réussi à trouver si il existait un moyen d'effectuer un SELECT dans n tables de la base (n non constant bien sûr), en spécifiant une condition (genre nom de la table commence par 'stock' par exemple).. une idée ?  
 
Merci
 
 

MagicBuzz a écrit :

non, c'est pas possible parceque ça sert à rien.


 
Mieux vaut lire ca que d'être aveugle !!!!
 
Select a.nom,b.nom,c.nom
from table1 a,table2 b,table3 c
where a.nom .....
 
Pour affecter les noms des tables  
 1. faire des requetes dynamiques.
 2. construire la requete par programme.
 

Reply

Marsh Posté le 13-03-2007 à 15:33:35    

En même temps, des jointures dynamiques ça implique un peu plus que de mettre le nom de la table dans from...
Ca peut-être utile mais pour des cas très (très) spécifiques. Mais vu les questions précédentes, je pense qu'il y a un problème de modélisation de la base.
D'un point de vue technique, c'est possible, en passant par de la génération automatique des requètes par un langage tiers ou encore par des procédures.

Message cité 1 fois
Message édité par RiderCrazy le 13-03-2007 à 15:33:58
Reply

Marsh Posté le 13-03-2007 à 15:33:35   

Reply

Marsh Posté le 13-03-2007 à 15:39:08    

RiderCrazy a écrit :

En même temps, des jointures dynamiques ça implique un peu plus que de mettre le nom de la table dans from...
Ca peut-être utile mais pour des cas très (très) spécifiques. Mais vu les questions précédentes, je pense qu'il y a un problème de modélisation de la base.
D'un point de vue technique, c'est possible, en passant par de la génération automatique des requètes par un langage tiers ou encore par des procédures.


 
remarque ca tombe bien parceque je parlais de requete dynamique
et ca s'utilise pas souvent c'est vrai...quoi que  
 

Reply

Marsh Posté le 13-03-2007 à 16:05:24    

Merci pour vos réponses, j'apprends plein de choses.
 
Si les jointures multiples et les requêtes dynamiques sont si compliquées et/ou rarement utiles que ça, c'est probablement un problème de modélisation de la base en effet.
 
Pour revenir à mon problème initial (on y est toujours d'ailleurs mais bon), j'ai lu le post de la signature de MagicBuzz, et j'ai travaillé sur la base, j'en arrive à quelque chose comme ça :
 
(Rappel de ce que je voulais :
- différentes "stations de stockage", permettant de stocker plusieurs produits, le nombre de ces emplacements est amené à varier
- différents produits, chacun stockés dans une station de stockage, avec des caractéristiques : référence, marque, etc.
 
- (1) trouver tous les produits d'une certaine station de stockage
- (2) trouver toutes les stations de stockage contenant un produit de marque 'Machin')
 
ARTICLES
id
reference
nom
prix
description
id_categorie
id_marque
id_stock
 
CATEGORIES
id
nom
 
MARQUES
id
nom
 
STOCKS
id
responsable
localisation
id_batiment
 
BATIMENTS
id
nom
 
Et pour les requêtes (1) et (2), j'aurais pas exemple :
(1) SELECT nom, reference FROM articles WHERE id_stock='bidule' (ben une requête toute simple quoi)
(2) SELECT stocks.id, stocks.localisation FROM stocks INNER JOIN articles ON articles.id_stock=stocks.id WHERE articles.id_marque=(SELECT id FROM marques WHERE nom='Machin')
 
Pourriez-vous me dire ce que vous en pensez ?
 
Merci

Reply

Marsh Posté le 13-03-2007 à 16:17:34    

Pour la (2) ca marche pas ca ?
 
SELECT stocks.id, stocks.localisation  
FROM stocks, articles, marques
where articles.id_stock=stocks.id  
   and articles.id_marque= marques.id
   and marques.nom='Machin'

Reply

Marsh Posté le 13-03-2007 à 16:19:49    

neoeven a écrit :

Mieux vaut lire ca que d'être aveugle !!!!


si tu relis la question, Edinbour parlais de faire X tables :
 
depot1
depot2
depot3
etc.
 
hors, on ne fait pas ça.
 
on fait une seule table, avec un champ discriminant qui permet de savoir de quel dépot on parle, mais en aucun cas autant de tables que de dépôts.
 
point.

Reply

Marsh Posté le 13-03-2007 à 16:21:44    

MagicBuzz a écrit :

si tu relis la question, Edinbour parlais de faire X tables :
 
depot1
depot2
depot3
etc.
 
hors, on ne fait pas ça.
 
on fait une seule table, avec un champ discriminant qui permet de savoir de quel dépot on parle, mais en aucun cas autant de tables que de dépôts.
 
point.


 
Mes excuses... My Lord
 
sincerement !!!

Reply

Marsh Posté le 14-03-2007 à 17:48:19    

Merci à tous, je vais pouvoir continuer avec toutes les infos que vous m'avez données et ce que j'ai appris sur le forum.
 
A un de ces jours pour de nouvelles questions ! :)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed