Bonjour l'élite. J'ai absolument besoin de transformer le site de mon épouse, qui présente des galeries de peintures numérique. J'opte sans conteste pour PHP/MySql... Malgré les centaines de pages lues, CD de formations etc, un coup de pouce "Malin" serait le bien venu ! Je ne sais comment articuler ma BDD intelligemment : Une table par catégorie d'images (portrait, femmes, enfants, anges, antique, etc.) mais comment faire correspondre un ID sur chaque tables, lors d'une recherche (ou d'une MAJ) du type : "portrait d'ange femme " ? Voilà, j'aimerai commencer sans aller dans le mur dès les premières lignes d'écriture. Merci à tous pour votre savoir... @+

Bonsoir,
la première chose à lire (ou à chercher) est comment normaliser une base de données pour éviter de faire des trucs trop moches, c'est à dire qu'il faut normaliser autant que possible (sauf dans le cas ou c'est pénalisant pour la rapidité d'execution), mais bon vue l'utilisation de la base (en gros un album photo classé) ça devrait presque sortire déjà normalisé ...

Moi perso, si ferais une base avec une table pour les fichiers image et leur description , une autre avec les mots clefs et une pour attribuer les mots-clefs aux images.

Maintenant, c'est la première idée qui me vient, donc je développe pas trop comme ça si d'autres sont pas d'accord avec moi on aura pas pollué le site pour rien.

Qu'en pensent les autres ?

OK, je vois en grande ligne le principe, mais là ou je pêche le plus, c'est dans les liens par ID entre les tables : un chiffre comme identifiant suffit-il à lier 4 ou 5 tables ? Au quel cas, comment le mettre en place ? Je suppose qu' il n'est pas envisageable d'organiser une Bdd sur un identifiant unique... De plus dans ta suggestion, tu ne fais que deux tables, serait il plus judicieux d'en créer une par catégorie d'illustration ? Merci pour un peu plus de détails.

Bonjour,
exactement, je ne sais pas quelle est la représentation la plus judicieuse pour les catégories, celà dépend vraiment la logique à employer; mais à première vue je resterais sur 1 seule table pour les oeuvres avec une colonne identifiant la catégorie (un nombre).

Dans mon exemple, j'avais pris 2 tables, mais c'était pour faire volontairement court celà dépend les informations qu'il y a à manier; c'est pour celà que j'avais parlé de la normalisation car en normalisant on s'aperçoit que ce que l'on comptait mettre en 1 table devra peut-être être "éclaté" sur 2 ou 3 tables.

Pour répondre à ta question sur l'ID, oui il peut tout à fait servir à lier plusieurs tables. Si ton id est un nombre auto incrémenté tu as sous MySQL une fonction LAST_INSERT_ID() pour laquelle tu pourras trouver des explications sur le site de mysql. Cette fonction qui existe sous une forme ou une autre dans beaucoup de langages (mysql_insert_id() pour PHP, via JDBC pour Java, ...) permet de récupérer la valeur de l'auto-incrément.

Une fois la valeur récupérée, tu n'as plus qu'à l'utiliser dans les autres tables pour identifier ton information. Ce qui n'empêche pas que chaque table pourra avoir une clef perso. Ce numéro est juste un lien pour identifier une information.
Je rappelle que tu peux faire le lien grace à un JOIN ou avec table1.id=table2.id

...

Pour mettre un peu de concret, un exemple tout simple
Table tbl_oeuvre:
id entier auto-incrémenté
titre texte
fichier texte

Table tbl_type
id entier auto-incrémenté
type_d_oeuvre texte

Table tbl_peinture
oeuvre_id entier (=tbl_oeuvre.id)
type_id entier (=tbl_type.id)
date_creation date
...

Voilà

Génial, je vais plancher sur ce principe, et tester une partie du process pour évoluer sereinement. Merci beaucoup.