pour une gestion de stock, koi choisir?

pour une gestion de stock, koi choisir? - SQL/NoSQL - Programmation

Marsh Posté le 28-01-2003 à 22:17:38    

voila, je suis totalement debutant dans les base de données mais j'aimerais kan meme en faire une... donc voila le premier pb ke je rencontre:
 
j'aimerais faire une gestion de stock informatique mais voila:
vo-t-il mieux faire une grosse TABLE nommé CARTE, ou dedans on met:
 
ID  modele                type  
1   a7n8x                 mobo
2   SBL 5.1               son
3   realteck 8039         reseau
4 etc....
 
ou bien une table par modele de carte???
MOBO
ID_mobo      modele_mobo
1              a7n8x
2             a7v333
....
 
REZO
ID_rezo         modele_rezo
1               realteck 8039
2                 3com905
....
 
 
 
je pose cette kestion ki me parait jouer de facon importante ds la facon de gerer la BDD...
 
 
merci de donner des conseils!

Reply

Marsh Posté le 28-01-2003 à 22:17:38   

Reply

Marsh Posté le 28-01-2003 à 22:56:38    

2eme solution

Reply

Marsh Posté le 28-01-2003 à 22:58:42    

Une seule table avec toutes les références, ca me semble mieux :)  
Imagine que tu ajoutes une table stockant le panier d'un utilisateur (IdUser, IdReference, Qte). Ce serait bien de pouvoir faire une jointure sur le IdReference vers une unique table :)  
 
Sinon, j'aime pas trop le type sous forme de chaine de caractères. Je préfère un entier, en définissant les constantes correspondantes dans les scripts.

Reply

Marsh Posté le 28-01-2003 à 23:07:31    

mrBebert a écrit :

Une seule table avec toutes les références, ca me semble mieux :)  
Imagine que tu ajoutes une table stockant le panier d'un utilisateur (IdUser, IdReference, Qte). Ce serait bien de pouvoir faire une jointure sur le IdReference vers une unique table :)  
 
Sinon, j'aime pas trop le type sous forme de chaine de caractères. Je préfère un entier, en définissant les constantes correspondantes dans les scripts.


 
peux-tu developper un peu plus ton premier paragraphe .... comme je le disais à ma premiere phrase, je suis newb des bdd...
 
pour info, je voulais créer ce systeme de bdd sous mysql et les clients se connecteront à la base PHP....
je veux faire avant tout kkch de simple ava,t tout :D  c pour me faire la main...
 
merci des reponses!!! :jap:  

Reply

Marsh Posté le 28-01-2003 à 23:11:28    

sPiKe a écrit :

2eme solution


 
pourrais tu etre un peu plus objectif, et me dire pkoi tu choisirais cette solution et pas la premiere???

Reply

Marsh Posté le 28-01-2003 à 23:20:02    

divx77 a écrit :


 
peux-tu developper un peu plus ton premier paragraphe .... comme je le disais à ma premiere phrase, je suis newb des bdd...
 
pour info, je voulais créer ce systeme de bdd sous mysql et les clients se connecteront à la base PHP....
je veux faire avant tout kkch de simple ava,t tout :D  c pour me faire la main...
 
merci des reponses!!! :jap:

Pour résumer : stocker des info, c'est bien. Mais les utiliser, c'est mieux :)
Généralement, tu as besoin de faire des jointures, c'est à dire de récupérer des champs venant de plusieurs tables en les mettant en relation entre eux. Dans ce cas, c'est plus pratique d'avoir toutes les références dans une même table plutot que d'aller piocher dans différentes tables qui, en fait, contiennent les même données.
 
Par exemple :
Tu as une autre table définissant le contenu du panier des utilisateurs (3 colonnes : l'Id du user, l'Id du produit, la quantité). En faisant une jointure, tu peux récupérer en une seule requête le contenu du panier d'un utilisateur avec les références correspondantes aux produits.
Si tu sépares les références, tu devras faire autant de requêtes que tu as de tables (1 requête pour récupérer les cartes mères, 1 pour les cartes réseau, 1 pour les HD .....).
 
De plus, le jour où tu rajoutes un type de matériel, tu dois créer un nouvelle table et modifier tous les scripts pour qu'ils l'utilisent. On s'en sort plus :pt1cable:


Message édité par mrbebert le 28-01-2003 à 23:21:47
Reply

Marsh Posté le 29-01-2003 à 00:01:59    

mrBebert a écrit :

Pour résumer : stocker des info, c'est bien. Mais les utiliser, c'est mieux :)
Généralement, tu as besoin de faire des jointures, c'est à dire de récupérer des champs venant de plusieurs tables en les mettant en relation entre eux. Dans ce cas, c'est plus pratique d'avoir toutes les références dans une même table plutot que d'aller piocher dans différentes tables qui, en fait, contiennent les même données.


 
tu es prof ou koi toi??? :ouch:  
merci bcp!!!!
 
 

mrBebert a écrit :


Par exemple :
Tu as une autre table définissant le contenu du panier des utilisateurs (3 colonnes : l'Id du user, l'Id du produit, la quantité). En faisant une jointure, tu peux récupérer en une seule requête le contenu du panier d'un utilisateur avec les références correspondantes aux produits.
Si tu sépares les références, tu devras faire autant de requêtes que tu as de tables (1 requête pour récupérer les cartes mères, 1 pour les cartes réseau, 1 pour les HD .....).
 
De plus, le jour où tu rajoutes un type de matériel, tu dois créer un nouvelle table et modifier tous les scripts pour qu'ils l'utilisent. On s'en sort plus :pt1cable:


 
OKKKKKKKK   merci :jap:  
 
mais la tu as tout fais à ma place  :cry:  
merci encore mrBebert


Message édité par divx77 le 29-01-2003 à 00:03:24
Reply

Marsh Posté le 29-01-2003 à 19:16:59    

divx77 a écrit :

tu es prof ou koi toi??? :ouch:  
merci bcp!!!!

 
 
 
OKKKKKKKK   merci :jap:  
 
mais la tu as tout fais à ma place  :cry:  
merci encore mrBebert

nan, mais j'en ai pas mal dans ma famille, ca doit venir de là :D  
 
Et puis SQL, je commence à connaitre :pt1cable:  
Si t'as d'autres questions, hésites pas :)

Reply

Sujets relatifs:

Leave a Replay

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