MySQL ... conseils pour les tables...

MySQL ... conseils pour les tables... - PHP - Programmation

Marsh Posté le 25-11-2003 à 13:06:00    

Bonjour à tous !! je voudrais des petits conseils pour mes tables de MySQL...
 
Pensez vous qu'il est mieux de faire plusieurs tables differentes ?
(genre une pour la prise de coordonnées, une autre pour les commandes, une autre pour les devis, une autre pour telle ou telle chose...)  
 
Sachant que j'ai des formulaire qui deviennent de plus en plus complexes... et que les utilisateurs devraient avoir acces à toute sorte des base des sa connexion...
 
Est il possible de lier les tables entre elles?
(à savoir... un identifiant correspondant à un table... et des infos le concernant sur une autre table... etc etc)
 
voila j'aimerai des conseils pour eviter d'avoir des tables qui font dix kilometres... et surtout de tout avoir à recommencer après...
 
Merci d'avance
 
Freed


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 13:06:00   

Reply

Marsh Posté le 25-11-2003 à 13:19:53    

l'idéal dans une base de données est de ne pas avoir la même information répétée 2x, donc on "normalise" (ce qu'on appelle les formes normales)
Si tes formulaires présentent la même chose avec un nom différent, tu peux toujours les fourrer dans la même table avec un champ pour identifier le type de formulaire.
 
Oui, on peut lier les tables entre elles: InnoDB est le type de table qui convient pour gérer les clés étrangères.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2003 à 13:40:36    

l'ideal alors serait de creer un identifiant... et plusieurs tables par rapport à cet identifiant ?


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 13:44:03    

euh j'ai pas compris [:tinostar]
 
t'as des notions de db relationnelles? :??:


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2003 à 13:47:23    

bah pas trop pour l'instant je ne sais que creer une base, creer une table, l'alimenter, et afficher son contenu... c tout !! alors j'ai plein de choses à apprendre encore ! mais j'aimerai pas faire de betises !


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 14:05:00    

freed102 a écrit :

bah pas trop pour l'instant je ne sais que creer une base, creer une table, l'alimenter, et afficher son contenu... c tout !! alors j'ai plein de choses à apprendre encore ! mais j'aimerai pas faire de betises !


 
bin en faite tu crées  pleins de tables correspondant chacune a une entité spécifique  (personne, commande , produit ,..) etc..
en gros comme ca a deja était dis tu decoupe de teelle sorte que ca soit coherent et sans doublons.
 
et les relation entre elle marche comme ca
 
exemple
 
table  client  
 
id_client
nom
prenom
..
..
 
table produit  
id_produit
nom_produit
.....
..
 
table commande
id_commande
id_client
id_produit
...
..
 
ensuite dans tesrequetes tu fais des jointures  
en faisant des rechrece tu devrais trouver comment faire des jointures
 
voila
je sais aps si c'est ce que tu voulais


Message édité par saxgard le 25-11-2003 à 14:09:03
Reply

Marsh Posté le 25-11-2003 à 14:08:58    

si si je vois à peu pres comment fonctionner.... c comme ça que je l'imaginais... juste que je savais pas comment lier les tables entre elles (pour que les donnée d'un client corresponde à sa commande...tout betement !)... mais tu me dis que c possible.. donc c bon ! :)
 
ça va pas etre facile avec mes valeurs dans une feuille excel... mais bon il doit bien y avoir un moyen !
 
merci en tous cas ! :)


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 14:09:49    

freed102 a écrit :

si si je vois à peu pres comment fonctionner.... c comme ça que je l'imaginais... juste que je savais pas comment lier les tables entre elles (pour que les donnée d'un client corresponde à sa commande...tout betement !)... mais tu me dis que c possible.. donc c bon ! :)
 
ça va pas etre facile avec mes valeurs dans une feuille excel... mais bon il doit bien y avoir un moyen !
 
merci en tous cas ! :)


 
bah de rien  , j'ai pas du trop t'aider alors  ;)

Reply

Marsh Posté le 25-11-2003 à 14:11:49    

Citation :


exemple
 
table  client  
 
id_client
nom
prenom
..
..
 
table produit  
id_produit
nom_produit
.....
..
 
table commande
id_commande
id_client
id_produit
...
..
 


 
cela m'aide deja pas mal ! je vais deja pouvoir commencer à faire une architecture correcte avec ça je pense...


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 14:11:54    

bon en gros:
si t'as un système disons de facturation, le problème se définit comme suit:
tu factures des articles à des clients
 
Tu définis tout en entités: t'as une table clients avec les infos de chaque client (un identifiant unique, nom, adresse, etc.), une table avec tes articles (identifiant unique, libellé, prix unitaire, etc.), pis la facture.
 
La facture doit reprendre les données du client et les articles commandés (avec la quantité pour chacun).
 
Première chose, tu vas pas recopier les données clients dans la facture elle-même, tu vas relier ta facture au client. Dans ta table factures, tu vas donc avoir un champ qui indique l'identifiant du client. Ceci est une relation. Le champ en question sera ce qu'on appelle une clé étrangère, et te permet d'avoir l'identifiant pour aller retrouver les infos du client dans la table liée. Deuxième chose, tu vas pas créer autant de lignes dans ta table facture qu'il y a d'articles commandés, ça impliquerait de dupliquer des données telles que le numéro de client, la date de facture, le total, etc.  Tu vas plutôt créer une seconde table facture_details par exemple, laquelle va répertorier les identifiants des articles commandés (ce champ sera donc une clé étrangère également), la quantité pour chaque article, etc.
 
La clé étrangère tient lieu de référence vers un identifiant unique d'une autre table. Cet identifiant unique est la clé primaire. 'fin il suffit pas de le dire, il faut aussi le préciser dans la définition de ta base de données.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2003 à 14:11:54   

Reply

Marsh Posté le 25-11-2003 à 14:18:20    

okok là tu as été parfait sur ce coup là ! j'y vois de plus en plus clair... je t'en remercie !!
en fait j'avais deja cree une table "connexion" (qui est en fait une table "client"... je vais la renommer ainsi... c plus clair... cette table commence par un champ "id" avec auto-increment... je sais pas si ça peut m'etre utile... et j'avais une autre table avec toutes les autres données (qui composent la commande du client)... j'ai pas encore la partie "articles"... c là que je veux faire intervenir ma feuille excel (surement grace à un fichier CSV)...
 
finalement je suis pas trop loin de ce que tu m'as dit... me reste à apprendre comment lier les tables avec une "clé etrangere"... je vais faire mes recherches ! :)


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 14:27:36    

l'autoincrement est intéressant si tu n'as pas d'autre méthode sûre (on va même dire parfaite) pour identifier quelque chose, c'est aussi la plus simple à mettre en oeuvre.
 
Attention, en MySQL, les clés étrangères ne peuvent être utilisées avec les tables de type MyISAM. Ou plutôt il y a une nuance. Avec des tables InnoDB, tu peux mettre cette logique au niveau du serveur de base de données en spécifiant quelles sont ces relations (tu peux imaginer par exemple que MySQL t'interdira de supprimer un client qui a des factures à cause de la relation existante que tu auras pris soin de spécifier entre client et facture). Avec du MyISAM, cette logique sera obligatoirement dans ton code et sera plus difficile à gérer.
 
D'autre part, MyISAM est très bien pour les tables plus souvent en consultation qu'en écriture; quant à InnoDB, c'est le contraire.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2003 à 14:30:33    

alors là j'ai des choses à apprendre... je connaissais pas l'existence de ces fameux MyISAM et InnoDB... Sont-il des  environnements du style PHPMyAdmin ou similaire ?
 
PHPMyAdmin me suffirait il pas pour ce genre d'actions ?


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 14:34:18    

de toute façon tu peux lancer des commandes directement avec PHPMyAdmin (ou n'importe quel SQL manager) donc oui :D


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 25-11-2003 à 15:49:17    

derniere question... dois-je mettre un ID (auto increment) sur toutes mes tables ? il va creer un id à chaque fois.. est ce necessaire ?


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 15:51:07    

non ce n'est pas nécessaire. Cela dépend des cas.

Reply

Marsh Posté le 25-11-2003 à 15:53:08    

dans mon cas.. chaque table sera liée par un id "client"... faut que les infos de chaque table soit "synchro"... c facile à faire ça ?


---------------
Freed102
Reply

Marsh Posté le 25-11-2003 à 15:57:20    

ben une règle à suivre est de ne jamais modifier une clé primaire, d'ailleurs dans un contexte de bdd relationnelle, le bdd ne te le permettra pas si l'info est référencée ailleurs. (mais vaut mieux ne *jamais* changer)
 
donc pas touche non plus aux clés étrangères (sauf si par exemple, tu te gourres de client ou d'article dans ta facturation, c'est plus un problème d'origine fonctionnelle que technique)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Sujets relatifs:

Leave a Replay

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