Demande d'information sur la validation

[Rhombus]

J'aimerais connaitre le coté fonctionnel de la validation.

Lorsqu'une personne modifie une entrée dans la BDD :
- Vous faites un doublon, donc une "ancienne entrée" est gardé
- La nouvelle entrée est affiché
- Le doublon est validé
- L'ancienne entrée est supprimé

C'est comme ca que ca fonctionne ? Si il y a deux modifications, deux doublons ?

[Beltana]

De quelles données parles-tu?

Car au niveau de la bdd, c'est un accès réservé à l'équipe. On modifie, pas de doublon.

[Rhombus]

Par exemple lorsqu'on modifie un point sur la carte, il n'y a pas une validation de votre part ?

[Beltana]

Le changement est effectif tout de suite sur la carte, mais il y a vérification de tous les changements et retour à la bonne version si nécessaire dans les jours qui suivent.

[Rhombus]

Le changement est effectif tout de suite sur la carte, mais il y a vérification de tous les changements et retour à la bonne version si nécessaire dans les jours qui suivent.

Le retour est fait grâce à une deuxième table dans la BDD ou des copies des auvegarde  dans la même table ?

[Enox]

Je te trouve bien curieux 

Il y a une table de référentiel propre, et une table "sale" dans laquelle sont prise en compte les modif, il y a une 3e table qui s'occupe du versionning.

La table de versionning sert a présenter les changements, qui sont soient validés, soit rejetés
Une fois l'ensemble des modifications modérées, la table sale est reconstruite a partir du référentiel.

[Rhombus]

C'était de la curiosité, j'ai cherché pas mal de temps pour trouver le meilleur moyen de faire un système d'ajout en temps réel avec de la validation derrière.. Utiliser qu'une seule table m'a paru le meilleur moyen pour avoir un minimum de code.

Je n'ai donc qu'une table, chaque nouvelle modification est de suite affiché (grâce à la date de création de l'entrée), mais elle est tagué comme "A valider".
Une page resence toute les entrées à valider, et quand une entrée esty validé par l'admin, le tag deviens "Valider" et l'ancienne entrée est supprimé (grâce à l'ID de la précédente entrée qui est enregistrée dans la nouvelle entrée).

[Enox]

Le fait de n'utiliser qu'une seule table rend la requete de restitution plus lourde.
De plus en cas de spam, il faut modifier chaque valeur une par une.

C'est pour ca que j'ai opté pour un systeme multitable. Il y a toujours une copie "sécurisée" des données. Les données modifiées le sont, dans une table avec des index optimisés en lecture.
De plus ce modele me permet de recalculer des choses dynamiquement, et donc de gérer les points sur plusieurs maps (un point a bree est aussi présent au pays de bree, mais ce n'est qu'un seul point dans mon référentiel)

[Rhombus]

Dans ma table, quand je dis qu'une modification et enregistré et tagué comme validé, ca veut dire que c'est en réalité une copie d'une entrée précédente.
Quand je la valide  (grâce à un lien), l'ancienne entrée est supprimé, la nouvelle est tagué comme validé et n'apparait donc plus dans la page qui recense les validation.

Je peu aussi faire un historique des modifications en taguant les anciennes comme archive.

En cas de spam, j'ai les 20*valeur qui s'affiche dans la page de validation. J'ai un système de case à cocher pour supprimer plusieur demande à la fois.

[Enox]

affaire de gout. Ce fonctionnement que tu décris pénalise l'utilisateur qui ne souhaite que consulter car tes requetes de consultations sont perturbées par ton mécanisme d'update.

Certes, pris unitairement, la pénalisation est minime, voir invisible, mais elle n'en reste pas moins présente. En construisant lotro.fr, nous avons anticipé notre succès et donc tout fait pour que chaque accès en consultation soit le plus optimisé possible, afin d'éviter d'avoir a changer de serveur quand le nombre de requetes simultannées rendra visible ses erreurs de conception.

Mon ancienne bdd (daea-guilde) était basé sur un systeme de modification monotable, axé sur un numéro de version. Assez similaire au système que tu décris. Nous n'avons pas souhaité reproduire ce modele sur lotro.fr pour les raisons décrites plus haut.

[Rhombus]

Il suffit de faire la bonne requête et de sélectionner en retour que ce que tu affiche.

[Titerris]

Ca va les techos, vous allez quand même pas nous taper des SELECT en veux tu en voila, et nous parler de cardinalité et de MCD

 

[Enox]

Tu peux faire le select que tu veux, si le modele est bancal a la base, le select sera mauvais. Encore une fois tout est question de priorité. modele plus simple mais plus lent (monotable) ou plus complexe mais optimisé en lecture (multitable). Il n'y a pas de bonne ni de mauvaise solution, tout dépend du contexte.

Sinon l'asticot on peut parler de MaCDo

[Rhombus]

Si la charge deviens importante => Mise en cache.

[Enox]

Pourquoi viens tu demander comment nous fonctionnons si tu as déja la solution magique ?