Structure table SQL pour une architecture communautaire?

Structure table SQL pour une architecture communautaire? - SQL/NoSQL - Programmation

Marsh Posté le 13-09-2009 à 22:36:11    

Bonjour à tous,

 

Sur un de mes projets, je me retrouve devant une problématique :
Supposons que j'ai une table mysql "artiste" avec une structure simplifiée comme celle-ci : artiste(id_artiste, nom, prenom, adresse).

 

Ce projet a pour but d'être communautaire, pour que les internautes puissent corriger la fiche d'un artiste si celle-ci est fausse/incomplete. Les internautes peuvent donc modifier une fiche, mais je dois passer derrière pour valider la fiche, pour éviter tout abus/spam/flood etc. Il me faut donc garder une trace des anciennes propriétés de l'artiste, avant qu'il ne soit modifié, pour pouvoir la restaurer la fiche si besoin est.

 

Je vois 2 solutions pour le moment:
1) Ajouter un 2e champ pour chaque champ déja existant, qui servira a sauvegarder l'ancienne valeur. Ma table ressemblera donc à cela : artiste(id_artiste, nom, nom_old, prenom, prenom_old, adresse, adresse_old)

 

2) Créer une nouvelle table "artiste_temp" qui sera la nouvelle fiche modifiée. Cette nouvelle table a la même structure que celle existante. Son intéret est de ne pas "polluer" la structure de la table artiste existante.

 

J'ai pensé à ces 2 méthodes et non une vraie table historique, car je n'ai pas besoin de garder une trace de chaque modification. Une fois que la fiche est modifiée, n'importe qui peut la modifier ensuite. Quand je passerai valider la fiche, je ne verrai ces modifs comme une seule modif. Et je valide ou pas, en écrasant les anciennes valeurs par les nouvelles.

 

Ma question est donc : voyez-vous d'autres solutions pour mon cas?
Merci beaucoup.


Message édité par welcominh le 13-09-2009 à 22:38:19

---------------
Direct-download.com, le moteur de recherche pour Mega
Reply

Marsh Posté le 13-09-2009 à 22:36:11   

Reply

Marsh Posté le 13-09-2009 à 22:47:59    

moi je créérais 3 tables :
- une table "artiste" qui contient le strict minimum : id_artiste
- une table "artiste_modifs" : f_id_artiste, f_id_user, nom, prenom, adresse...
- une table "user" qui contient les infos utilisateur : id_user, nom, prénom, etc...

 

la table centrale est la table "artiste_modifs" qui est une table de liaison entre la table "artiste" et "user" (via les clés étrangères f_id_artiste et f_id_user. en ajoutant dans cette tables toutes les infos modifiables de l'artiste, tu suis exactement toutes les modifs faites dessus.

 

car ta solution comporte un inconvénient : que se passe t'il si 2 utilisateurs valident une modif fausse ? imagine le scénario suivant :

 

- user 1 modifie la fiche, en saisissant une info erronée
- peu après (disons 10 secondes, pour que tu n'aies pas le temps de valider les modifs de user 1), user 2 modifie la fiche en mettant aussi des infos erronées.
- tu arrives, et tu constates que user 2 a écrit des conneries. donc tu récupères la modif précédente, celle de user 1, qui est aussi erronée. tu fais quoi ? tu n'as d'autre choix que de restaurer la fiche d'origine, en écrasant toutes les éventuelles modifs correctes faites par d'autres users.

 

c'est pourquoi je te conseille de garder l'historique de tes modifs, via la structure que je te propose

 


Message édité par Harkonnen le 13-09-2009 à 22:49:26

---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 15-09-2009 à 11:44:54    

Bonjour Harkonnen,

 

Il y a une (très) légère différence de compréhension je crois. Je reprendre ton scénario pour éclaircir:

 

1) user 1 modifie la fiche, en saisissant une info erronée
2) peu après (disons 10 secondes, pour que tu n'aies pas le temps de valider les modifs de user 1), user 2 modifie la fiche en mettant aussi des infos erronées.
3) tu arrives, et tu constates que user 2 a écrit des conneries. donc tu récupères la modif précédente, celle de user 1, qui est aussi erronée. tu fais quoi ? tu n'as d'autre choix que de restaurer la fiche d'origine, en écrasant toutes les éventuelles modifs correctes faites par d'autres users.

 

Voici le comportement que je souhaiterais de l'appli:
1) ok. L'orginale est sauvegardée. La nouvelle fiche est sauvegardée et est visible directement et publiquement.
2) User2 modifie juste après user1. User2 écrase donc la fiche de user1. (en mettant à jour / ou en publiant des conneries c'est selon). La nouvelle fiche visible est donc User2.
3) User2 a écrit des conneries. Je ne récupère pas la fiche de user1, car elle n'existe plus puisque qu'elle a été mise à jour par user2. (Il n'existe en fait qu'une fiche temporaire). Je récupère donc tout simplement la fiche d'orgine, celle que j'ai validé avant que tout internaute ne touche à quoique ce soit.

 

Lorsque j'arrive dans ma console d'admin, je vois une fiche qui a été modifiée. Je regarde les modifs. Si c'est OK, je valide, si ca ne l'est pas, je restaure. Je veux avant tout faire simple, et non gérer des "versions de fiche" au cas où un visiteur mettrait des conneries. Pouquoi? tout simplement une question de temps. OK? je valide. Pas OK? restaure basta, on passe vite à autre chose :) Donc en fait, mon objectif, c'est juste une fiche originale (ou plutot valide) et une fiche "temp".
Bien sur, ca sous-entend que les internautes ne fassent pas de conneries. (Car des modifs bonnes pourraient être gachées par des mauvaises).

 

EDIT: Hum, réflexion faite, l'idée d'une table qui stocke les modifs (artiste_modifs) n'est pas mal car la structure ne change pas.


Message édité par welcominh le 15-09-2009 à 13:20:00

---------------
Direct-download.com, le moteur de recherche pour Mega
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed