Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1533 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  MySQL ... conseils pour les tables...

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

MySQL ... conseils pour les tables...

n°575579
freed102
Arayashiki
Posté le 25-11-2003 à 13:06:00  profilanswer
 

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
mood
Publicité
Posté le 25-11-2003 à 13:06:00  profilanswer
 

n°575593
drasche
Posté le 25-11-2003 à 13:19:53  profilanswer
 

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)
n°575607
freed102
Arayashiki
Posté le 25-11-2003 à 13:40:36  profilanswer
 

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


---------------
Freed102
n°575611
drasche
Posté le 25-11-2003 à 13:44:03  profilanswer
 

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)
n°575613
freed102
Arayashiki
Posté le 25-11-2003 à 13:47:23  profilanswer
 

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
n°575627
saxgard
Posté le 25-11-2003 à 14:05:00  profilanswer
 

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
n°575629
freed102
Arayashiki
Posté le 25-11-2003 à 14:08:58  profilanswer
 

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
n°575631
saxgard
Posté le 25-11-2003 à 14:09:49  profilanswer
 

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  ;)

n°575632
freed102
Arayashiki
Posté le 25-11-2003 à 14:11:49  profilanswer
 

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
n°575633
drasche
Posté le 25-11-2003 à 14:11:54  profilanswer
 

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)
mood
Publicité
Posté le 25-11-2003 à 14:11:54  profilanswer
 

n°575637
freed102
Arayashiki
Posté le 25-11-2003 à 14:18:20  profilanswer
 

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
n°575643
drasche
Posté le 25-11-2003 à 14:27:36  profilanswer
 

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)
n°575648
freed102
Arayashiki
Posté le 25-11-2003 à 14:30:33  profilanswer
 

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
n°575653
drasche
Posté le 25-11-2003 à 14:34:18  profilanswer
 

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)
n°575744
freed102
Arayashiki
Posté le 25-11-2003 à 15:49:17  profilanswer
 

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


---------------
Freed102
n°575749
gizmo
Posté le 25-11-2003 à 15:51:07  profilanswer
 

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

n°575752
freed102
Arayashiki
Posté le 25-11-2003 à 15:53:08  profilanswer
 

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
n°575758
drasche
Posté le 25-11-2003 à 15:57:20  profilanswer
 

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)

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  MySQL ... conseils pour les tables...

 

Sujets relatifs
serveur MySQL free : supprimer une table dont le fichier .frm est HS?MySQL, fait pas la différence entre "e" et "é"
Question Mysql/php[MySQL] Erreur de syntaxe que je ne comprend pas ! (aléatoire en plus)
[noob][mysql] ou trouver les info pour peupler ma basemysql et phpmyadmin
J'ai encore buggé !! ... en MySQL cette fois ! :)MySql et les float
[php/mysql] Tester une chaine different de vide[MYSQL] Case sensitive ?
Plus de sujets relatifs à : MySQL ... conseils pour les tables...


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR