Comment structurer mes données ? - SQL/NoSQL - Programmation
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
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
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
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
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 y'a un truc qui s'appelle "jointures" et c'est là justement pour faire ça
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
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
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.
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.
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... |
remarque ca tombe bien parceque je parlais de requete dynamique
et ca s'utilise pas souvent c'est vrai...quoi que
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
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'
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.
Marsh Posté le 13-03-2007 à 16:21:44
MagicBuzz a écrit : si tu relis la question, Edinbour parlais de faire X tables : |
Mes excuses... My Lord
sincerement !!!
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 !
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