MySQL ... conseils pour les tables... - PHP - Programmation
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.
Marsh Posté le 25-11-2003 à 13:40:36
l'ideal alors serait de creer un identifiant... et plusieurs tables par rapport à cet identifiant ?
Marsh Posté le 25-11-2003 à 13:44:03
euh j'ai pas compris
t'as des notions de db relationnelles?
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 !
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
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 !
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 ! |
bah de rien , j'ai pas du trop t'aider alors
Marsh Posté le 25-11-2003 à 14:11:49
Citation : |
cela m'aide deja pas mal ! je vais deja pouvoir commencer à faire une architecture correcte avec ça je pense...
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.
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 !
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.
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 ?
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
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 ?
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 ?
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)
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