Annonces plusieurs rubriques et plusieurs départem

[Thibaut]

Salut à tous,

voila, en fait, je suis en train de créer un site en php + mysql.

J'ai déjà créé un espace membres, avec la modification de leurs comptes, et maintenant, je voudrais créer un page où les membres peuvent passer leurs annonces.

Ex : Boulangerie - Dordogne(24) - Prix - Commentaires - photos ...

Je sais créer le formulaire, mais ensuite, je ne sais pas comment envoyer les données du fomulaire dans la bonne rubrique (ex:"boulangerie"), et dans le bon département (ex:"dordogne(24)").

C'est à dire que je ne sais pas comment répertorier la page de la fiche de l'annonce, dans la bonne rubrique et le bon département.

Je ne sais pas si j'ai été très clair dans mes explications, donc si vous avez des questions, n'hésitez pas.

Merci d'avance à tous ceux qui pourront m'aider et à bientôt j'espère

Thibaut (17 ans)

[Earalia]

euh... je ne suis pas sure d'avoir compris...

en gros, tu veux une page qui répertorie toutes les annonces, en indiquant quelques données, dont la rubrique et le département ?

c'est ça ?

si oui, peux-tu dire un peu les tables MySQL que tu utilises, et les zones concernées ?

[Thibaut]

Bah en fait, je sais comment inscrire toutes les données du formulaire dans une base de données, mais ensuite, je ne sais pas comment les tier, pour que les personnes qui viennent voir le site cliquent que "boulangerie", et ensuite sur "dordogne(24)" pour afficher que les boulangerie de la dordogne, et pas toutes les autres.

Merci encore pour votre aide et pour la rapidité de votre réponse

Thibaut

[xpatval]

Ce sont les requêtes SQL qui te permettront cela. (Si j'ai bien compris la problématique).

SELECT champ1, champ2, champ3...from table1, table2..WHERE champ_profession = 'boulangerie';

xpatval

[Thibaut]

Ok, merci beaucoup !

je ne sais pas si c'est possible, mais si c'est le cas, est-ce que vous pourriez me faire juste un petit exemple ?

Merci encore et @++

Thibaut

[xpatval]

Tu dois avoir plusieurs tables dans ta base. Par exemple:

table profession:

id_profession

libelle

Table departement:

id_departement

libelle

Table dep_prof (table de jointure)

id_dep_prof

id_profession

id_departement

As-tu déjà ce genre de chose dans ta base ?

xpatval

[Thibaut]

Non, pour le moment, je n'ai que ma table "membres" qui contient les membres inscrits.

Ca y est, je viens de créer les 3 autres tables, mais je ne sais pas ce qu'est "libelle".

Je voudrais aussi savoir si je dois mettre tous les "id" en "autoincrement" et en "index" ?

Merci encore, ca me fait plaisir de rencontrer des personnes qui s'y connaissent et qui peuvent m'aider

Thibaut

[Earalia]

Les "id" seront les clés d'accès aux tables, donc oui, tu peux les mettre en autoincrement et en index.

C'est conseillé et plus propre, mais pas obligatoire.

Le libellé, c'est, en gros, synonyme de "titre"

[Thibaut]

Ok, et donc une fois que j'ai fait mes tables, qu'est-ce que je dois faire ?

Pourrais-je avoir un exemple de formulaire qui renvoie l'annonce automatiquement dans le bonne rubrique (métier) et dans le bon département ?

Merci et @ bientôt

Thibaut

[xpatval]

Pourrais-je avoir un exemple de formulaire qui renvoie l'annonce automatiquement dans le bonne rubrique (métier) et dans le bon département ?

Il vaudrait mieux que tu essaies par toi-même, afin de comprendre les rouages des différentes requêtes possibles.

Le formulaire en lui-même ne te posera pas de souci. C'est la récupération des données, leurs vérifications et leur insertion qu'il faut maîtriser.

Penche-toi du coté des commandes INSERT, UPDATE et DELETE, afin d'implémenter tes tables.

xpatval

[petit-ourson]

Les "id" seront les clés d'accès aux tables, donc oui, tu peux les mettre en autoincrement et en index.

C'est conseillé et plus propre, mais pas obligatoire.

<{POST_SNAPBACK}>

Pourquoi plus propre ?

Enfin je dirai que c'est plus simple mais pas forcément plus propre, enfin ça dépend du modèle conceptuel ;o)

Par exemple les "id_departement", j'espère qu'il ne seront pas autoindexé, car il va y avoir un problème avec la Corse du Nord et du Sud ;o)

Edit : il fallait lire "Haute-Corse" et non "Corse du Nord" ;o)

Modifié 23 Avril 2006 par petit-ourson

[xpatval]

Par exemple les "id_departement", j'espère qu'il ne seront pas autoindexé, car il va y avoir un problème avec la Corse du Nord et du Sud ;o)

Si l'on prend cette table en exemple, il faut bien entendu y mettre les champs nécessaires...

Par exemple:

table departement

id_departement en auto-incrément (la clé primaire)

libelle (en charset)

numero (en charset aussi)

xpatval

[petit-ourson]

ouaip où mettre le numero du département en clef primaire mais là ça va être bof car on va avoir une clef en char bien que sur 100 clefs, la différence de perf va-t-elle se faire ressentir ?

[xpatval]

Ben je dirais que le problème ne se pose pas vraiment, à partir du moment où une jointure est nécessaire entre les départements et les professions.

Il faut, AMHA, garder un index primaire pour cette jointure, et avoir un champ dédié au numéro du département

xpatval

[petit-ourson]

Pourquoi ?

Si ça n'aide pas niveau perf, on peut très bien utiliser un index primaire autre qu'un autoincrement.

[xpatval]

Je ne crois pas que les performances soient menacées par une requête sur une table qui ne contiendra qu'un centaine d'enregs, et puis j'aime bien différencier la clé primaire du reste...

Question d'habitude de prog...(mauvaise ?)

xpatval

[petit-ourson]

L'ajout d'un id autoincrementé doit se faire :

- au niveau du MCD si on ne trouve pas moyen de différencier chaque 'enregistrement' (or ici ce n'est pas le cas car le numéro du département est bien unique).

- au niveau du MLD (modèle logique de données) avec pour but l'optimisation.

Ici on se trouve dans le deuxième cas, mais sur 100 enregistrements, je ne suis pas certain que cela change grand chose.

Donc on passe le numero du déparetmeetn en clef primaire, il sera indexé et on s'embrouille pas avec deux numeros ;o)

[Thibaut]

Il vaudrait mieux que tu essaies par toi-même, afin de comprendre les rouages des différentes requêtes possibles.

Le formulaire en lui-même ne te posera pas de souci. C'est la récupération des données, leurs vérifications et leur insertion qu'il faut maîtriser.

Penche-toi du coté des commandes INSERT, UPDATE et DELETE, afin d'implémenter tes tables.

xpatval

<{POST_SNAPBACK}>

En fait, je sais me servir des commandes INSERT, UPDATE et DELETE parce que dans l'espace membres que j'ai fait, il y a bien entendu l'inscription (insert), la mise à jour du profil (update), et la suppression du compte (delete).

Je sais donc renvoyer les données du formulaire dans la base de données, mais je ne sais pas comment les afficher dans les bonne rubriques.

Merci encore à tous, vous êtes vraiment super

Thibaut