Discussion :

[Topinambour]

Bonjour à tous,

Tout d'abord désolé si je ne suis pas dans la bonne partie du forum pour vous faire part de mon problème. Il s'agit plus d'un problème global d'organisation de ma BDD que d'un problème technique MySQL (même si c'est le SGBDD que j'utilise).

Prenons un exemple pour illustrer mon problème :

Je souhaite dévolopper un site où les membres peuvent publier une annonce décrivant leur voiture. Leur du processus de création de l'annonce, ils sont amenés à remplir tout un tas de champs/cocher tout un tas de cases, etc, pour pouvoir entrer tout ce qui est nécessaire (description, critères, ...) dans la base de données.

On en vient à ma question : je souhaiterai que, une fois ce processus terminé, cette annonce ne soit pas publiée sur le site tant que l'administrateur ne l'approuve pas.
Bon a priori le plus simple est juste d'ajouter un champ dans ma bdd spécifiant si oui ou non cette annonce est validée. OK.

On en vient maintenant au vrai "problème". L'utilisateur aura toujours la possibilité d'éditer lui même son annonce (après publication sur le site), pour y modifier la photo, la description, que sais-je encore ... Mais encore une fois, ces modifications seront sujettes à la validation de l'administrateur, et en attendant cette validation l'annonce (dans son ancienne version) doit toujours etre disponible sur le site.

Du coup a priori il y a plusieurs possibilités : dupliquer chaque champ susceptible d'etre edité, ou alors avoir un duplicata de cette bdd (de ces tables) qui ferait tampon, i.e. stockerait les annonces apres modifs mais avant validation.
J'imagine qu'il y a d'autres solutions, possiblement encore meilleures.

Il me semble que ce genre de 'modération de modifications' est quelque chose qui est assez répandu, pourtant j'ai farfouillé des heures sur le net sans rien trouver de convaincant ... Un grand merci si vous avez la clé !

Topinambour

PS: Question subsidiaire : le top serait a la fin de voir immédiatement ce qui a été modifié par une opération qui trouverait la différence entre deux champs avant et apres modifs (pour voir par exemple quel mot a été changé). J'imagine que c'est possible en MySQL mais je sais aps trop quelle fonction utiliser. Mais bon, c'est accessoire.

Merci encore

[CinePhil]

Ça s'appelle une gestion de versions !

Dans Drupal, chaque noeud est identifié par son "nid" (id du noeud) et son "vid" (id de la version). Idem pour tout ce qui s'y rattache.

En s'inspirant de ce principe, tu peux avoir une table des annonces, une table des versions et X tables pour les propriétés des annonces qui font référence à la table des versions.

MCD :
annonce -1,n----avoir----(1,1)- version -0,n----associer----0,n- propriete

Tables :
annonce (anc_id, anc_id_auteur, anc_date_creation, anc_texte...)
version (vrs_id_annonce, vrs_num_version, vrs_est_validee...)
propriete (prp_id, prp_libelle...)
vrs_associer_prp (vap_id_annonce, vap_num_version, vap_id_propriete, vap_valeur...)

[Topinambour]

Tout d'abord merci pour la réponse !

Je pense déja qu'en me documentant sur la gestion de version je trouverai plus de choses.

Pour être sur d'avoir bien compris ce que tu préconises :

1 table "annonce" qui stockera les données immuables (qui ne peuvent etre modifiées par la suite)

1 table "version" qui determinera les versions existantes de chaque annonce (et leur validation)

X tables "propriete_x" gerant les differentes proprietes de l'annonce qui sont modifiables ?

Pas sur d'avoir compris cette table

(et ensuite la table de jointure (n,n), ok)

J'aurai tout de meme une interrogation, si tant est que j'ai bien interprété ce que tu as expliqué : lorsque l'on interrogera la base de données pour faire une recherche sur les annonces (et leur propriétés), il faudra spécifier de ne faire le select que sur les champs des tables proprietes correspondant a des versions validées (pour ne pas se retrouver avec des annonces 'anciennes versions')
Ca ne risque pas de 'bouffer' pas mal de temps ce genre de requete en plus ?

(C'est une question vraiment venant d'un ignorant vis à vis des performances MySQL et de ce qui ralentit ou non.)

[CinePhil]

Pour être sur d'avoir bien compris ce que tu préconises :

1 table "annonce" qui stockera les données immuables (qui ne peuvent etre modifiées par la suite)

1 table "version" qui determinera les versions existantes de chaque annonce (et leur validation)

X tables "propriete_x" gerant les differentes proprietes de l'annonce qui sont modifiables ?

Pas sur d'avoir compris cette table

Si ce ne sont que des annonces de voitures, tu pourras avoir par exemple une table pour les couleurs, une table pour les types (berline, coupé...), une table pour le carburant (sans-plomb, gazole, GPL,hybride, tout électrique) ou alors faire une modélisation par méta-données.

J'aurai tout de meme une interrogation, si tant est que j'ai bien interprété ce que tu as expliqué : lorsque l'on interrogera la base de données pour faire une recherche sur les annonces (et leur propriétés), il faudra spécifier de ne faire le select que sur les champs des tables proprietes correspondant a des versions validées (pour ne pas se retrouver avec des annonces 'anciennes versions')
Ca ne risque pas de 'bouffer' pas mal de temps ce genre de requete en plus ?

Non. C'est juste une condition sur la colonne "vrs_est_validee". De toute façon, tu auras sans doute besoin de joindre les tables annonce, version et les X tables de propriétés pour restituer l'annonce complète mais il ne faut pas avoir peur des jointures, c'est le principal boulot d'un SGBD et c'est l'opération la plus optimisée.

(C'est une question vraiment venant d'un ignorant vis à vis des performances MySQL et de ce qui ralentit ou non.)

Par contre, si ce n'est pas trop tard et si MySQL ne t'est pas imposé, intéresse toi plutôt à Postgresql.

[Topinambour]

Si ce ne sont que des annonces de voitures, tu pourras avoir par exemple une table pour les couleurs, une table pour les types (berline, coupé...), une table pour le carburant (sans-plomb, gazole, GPL,hybride, tout électrique) ou alors faire une modélisation par méta-données.

A vrai dire ce n'est pas une BDD sur les voitures, mais sur des voyages, ce qui ne change pas grand chose, sinon augmente un peu la complexité (par exemple chaque voyage peut avoir differentes dates de departs, ou differentes destinations -pour le cas d'un circuit).

Non. C'est juste une condition sur la colonne "vrs_est_validee". De toute façon, tu auras sans doute besoin de joindre les tables annonce, version et les X tables de propriétés pour restituer l'annonce complète mais il ne faut pas avoir peur des jointures, c'est le principal boulot d'un SGBD et c'est l'opération la plus optimisée.

Ok, c'est vrai que dans mon modele actuel j'ai deja un certain nombre de jointures.
Petite aparte : la colonne "vrs_est_validee" ne peut etre egale a 1 (et pas a 0) uniquement une fois par annonce_id (pour ne pas avoir deux versions de la meme annonce). C'est juste un détails à prendre en compte dans la validation ? A savoir que lors de la validation d'une version tu passes à 0 le champ "validation" de l'ancienne version ?
Désolé c'est sans doute une question stupide/evidente mais je manque d'experience dans ce genre de trucs

Par contre, si ce n'est pas trop tard et si MySQL ne t'est pas imposé, intéresse toi plutôt à Postgresql.

Ah non pour l'instant il n'est pas du tout trop tard, c'est juste que MySQL etait mon choix car je connais mieux et puis j'utilise Wamp avec phpMyAdmin.
Pour quelles raisons penses tu que PostgreSQL est plus adapté que MySQL dans mon cas ?

Merci beaucoup en tout cas, tu m'as oté une belle épine du pied