Filtrage Tableau par Liste deroulante.

[stevenP]

Bonjour !

Je dois créer une page web qui me permettrait de filtrer une liste dans une base de donnée par des choix dans des liste deroulante.

Cette page serait interfacé par une base de donnée, je bosse pour le moment en local avec WAMP.

Ma base de donnée se présente comme ceci :



Par exemple, j'ai sur ma page web cette présentation :



Si je fais un choix dans ma liste déroulante, le tableau en dessous sera Filtré par mon Champ choisi !

Je suis un peu perdu dans le démarrage.
-> Comment puis je procéder pour afficher ma base dans le tableau en dessous ?
-> Comment puis je filtrer cette base affiché par l'intermédiaire de mes listes ?

Merci beaucoup d'avance pour votre aide !
Cordialement,

Steven.

[rawsrc]

Bonjour,

Je te renvoie vers ce tutorial sur les listes liées en PHP, MySQL et AJAX : ici

[stevenP]

Bonjour,

Tout d'abord merci, c'est exactement ce principe que je recherche.

Je suis en train de suivre le tutoriel, mais.. je n'arrive pas à l'adapter à la forme de ma base de données.

Moi j'ai un plan du type :

nom de la Base : "xls_db"

avec 1 seule Table :

"base"
-> Product ID
-> ArticleProduit
-> ROS
-> RaisonSociale
-> Adresse
-> Ville
-> Code Postal

Faut-il structurer la table autrement ?

[stevenP]

Faut-il que je créé une table par champ ?

Plutot faire cette configuration :

"t_adresse"
-> idAdresse
-> Adresse

"t_ville"
-> idVille
-> Ville

"t_produit"
-> idProduit
-> ProduitID

"t_ROS"
-> idROS
-> ROS

En sachant qu'un "Produit" ne peut avoir qu'une Ville, qu'une adresse, et qu'un ROS. je peux lier la table Produit aux 3 autres tables ?

[rawsrc]

Si ton application est destinée à rester petite (cas d'école) pas besoin de tout restructurer. Par contre si elle prend de l'ampleur, suivre toutes les données dans une seule et unique table relève d'une sacrée gageure. A toi de voir.
(Je te conseillerai quand même de restructurer, mais chuuutt...)

Si tu conserves ta structure, il te suffit juste d'adapter les requêtes SQL en y ajoutant DISTINCT, sinon tu te cales sur mon tuto.
Par exemple :

Code sql :

SELECT DISTINCT xls_db.Ville FROM xls_db

[RunCodePhp]

Salut

En sachant qu'un "Produit" ne peut avoir qu'une Ville, qu'une adresse, et qu'un ROS. je peux lier la table Produit aux 3 autres tables ?

Je suis assez étonné.
Tu est sûr qu'1 produit ne peut être lié qu'à 1 ville et adresse et un ROS ?

Et si on pose le problème dans l'autre sens.
Est-ce qu'un ROS est obligatoirement lié à 1 produit ?
Est-ce qu'une adresse est obligatoirement lié à 1 produit (et le même que ci-dessus) ?
Est-ce qu'une ville est obligatoirement lié à 1 produit (et le même que ci-dessus) ?

Pour que les données soient dans une même table, il faut que les cardinalités soient (1-1) dans les 2 sens, sinon normalement la donnée doit sortir de la table pour y être dans une autre.


Si tu est vraiment sûr de ça (ci-dessus), normalement toutes ces données peuvent être dans une même table.


C'est quoi un ROS ?
Quel est le domaine/secteur si ce n'est pas indiscret ?

[rawsrc]

Quelques remarques avec ton schema :
Une adresse est rattachée à une ville, non ?
Et à moins de vouloir suivre toutes les rues communes à plusieurs villes, je pense qu'il n'est pas judicieux de séparer les adresses.
L'adresse devrait rester un champ texte rattaché au produit.
Suivre les villes séparément est une bonne idée.
Idem pour ROS (bien que je ne sache pas du tout ce que cela veut dire, mais j'aime jouer aux devinettes)

[stevenP]

Je pense donc que je vais restructurer ma base en plusieurs table !
En fait au départ j'ai une grosse base Excel de 3000 lignes avec 7 colonnes :
- Product ID (l'ID du produit)
- ArticleProduit (le type de produit)
- ROS (Qui est en fait Responsable Opérationnel Site, en gros celui qui gère la production !)
- RaisonSociale (Le client)
- Adresse (ex : 2 rue de la meuse)
- Ville (ex : Lille)
- Code postal (ex : 59000)

Je compte structurer ça correctement dans une base de donnée.

Au départ j'ai essayé de modifié comme cela pour le filtrage par ROS :

Code :

1
2
3
4
5
6
  // ROSS 
  $sql = 'SELECT DISTINCT base.ROS FROM base ORDER BY base.ROS;'; 
  $qry = mysql_query($sql); 
  while($row = mysql_fetch_row($qry)) { 
  $ROSs[$row[0]] = $row[1]; 
  }

Mais je pense restructurer ma base en 4 tables distinctes plutot ça sera plus judicieux vu que dans la continuité ce projet prendra de l'ampleur.

En gros, c'est ça.

Un Produit à une adresse, un code postal, une ville, un client, et un ROS.
Il ne faudrait pas créer des clés etrangères dans ma table "t_produit" pour les lier avec les clés primaires de mes autres tables ?

J'ai séparé les villes des adresses parce que au départ il peut y avoir un produit à une adresse A dans une Ville X, et un autre produit à une adresse B dans cette même ville X.

Mais comme je pense au final faire le filtre juste par Ville et afficher juste dans une colonne différente l'adresse et une autre le code postal.. Je ne sais pas si il est possible de faire ça si je sépare en 3 tables ?

Du coup je suis un peu perdu dans la structure de ma base ^^'.

Pour le secteur, Je travaille chez un grand opérateur telephonique ^^.

[stevenP]

Plutot faire cette configuration donc ?

"t_produit"
-> idProduit
-> idVille
-> idTypeproduit
-> idROS
-> idClient
-> ProduitID

"t_typeproduit"
-> idTypeproduit
-> typeproduit

"t_ville"
-> idVille
-> Ville
-> CodePost
-> Adresse

"t_ROS"
-> idROS
-> ROS

"t_client"
-> idClient
-> Client

?

[rawsrc]

Ok,
Un même produit dans plusieurs villes -> tu peux d'ores et déjà séparer la localisation de ta table produits. Un produit peut avoir de une à n localisations.
Ensuite pour les adresses, je pense que les gérer sous forme textuelle est parfait.

Ensuite pour le reste de la modélisation, il faut se poser des questions :
Est-ce qu'un ROS peut se voir confier la gestion de plusieurs sites ?
Est-ce l'adresse correspond à l'adresse du client / du site de prod / de l'adresse où est placé le produit...
Est-ce qu'même client peut être rattaché à plusieurs sites...
Bref, va falloir phosphorer

[rawsrc]

Envoyé par stevenP

Plutot faire cette configuration donc ?

"t_produit"
-> idProduit
-> idVille
-> idTypeproduit
-> idROS
-> idClient
-> ProduitID

"t_typeproduit"
-> idTypeproduit
-> typeproduit

"t_ville"
-> idVille
-> Ville
-> CodePost
-> Adresse

"t_ROS"
-> idROS
-> ROS

"t_client"
-> idClient
-> Client

?

Pas bon, corriges avec mon post précédent

[stevenP]

Pour faire plus simple regarde, j'ai modélisé l'exemple de base que j'ai sur excel au départ ! Chaque ligne est indépendante d'une autre !
En fait chaque ligne c'est un dossier !

[rawsrc]

Pourrais-tu répondre brièvement aux questions de mon post précédent ?
Et une autre question est ce que le suivi des sites est nécessaire ?

[stevenP]

Oui désolé !
1 ROS peut avoir traité plusieurs dossier.
L'adresse correspond à l'adresse du site de prod.
Un même client peut être attaché a plusieurs site !

Qu'entends tu par le "suivi des sites" ?

[rawsrc]

Envoyé par stevenP

Qu'entends tu par le "suivi des sites" ?

C'est dans le cadre de cette question : Est-ce qu'un ROS peut se voir confier la gestion de plusieurs sites ?

[stevenP]

Envoyé par rawsrc

C'est dans le cadre de cette question : Est-ce qu'un ROS peut se voir confier la gestion de plusieurs sites ?

En même temps ? Oui bien sur.

Mais en fait cette base sera (beaucoup) plus un Historique que du temps réel.

[rawsrc]

Ok,
Le client connait le nom du ROS qu'à cause du site de production.
Si son produit venait à changer de site de production, est ce son ROS changerait également ?

[stevenP]

Le produit ne peut pas changer de site de production ! ^^
En fait les produit, c'est des "liaisons haut débit"

En fait, c'est pour ça que je disais au départ qu'un produit ne peut avoir qu'une adresse (ville codepost' adresse), qu'un ROS (qui ne change pas tout le long de la prod), qu'un client (une entreprise), qu'un type. C'est parce que tout est défini au départ (sauf le ROS qui est défini après et c'est justement à ça que servirai mon projet ^^, en fonction du filtrage par Ville, par type, et par client, On puisse voir les ROS qui ont déja travaillé sur des productions similaires !

[rawsrc]

Allez je te propose ceci :

[stevenP]

Merci ce schéma est très bien.
J'me suis ajouté les 2 champs "id_client" et "client" sur la table "t_client".
Mais j'émet un doute sur la table "t_produit".
Il n'y a pas plus de clé étrangère ?
Juste id_type_produit ? Parce que comme je disais chaque dossier (donc chaque "id_produit" est considéré comme totalement autonome, et c'est pour ça que je disais qu'un "id_produit", possede un "cp_ville", un "nom_ville", une "adresse_produit", un "client", et un "nom_ros".
En gros, l'identifiant du Produit est au centre, et on vient lui ajouter les informations.
C'est pour ça que j'aurais ajouté d'autre clé étrangère à la table "t_produit".
Ce n'est pas possible ?