Bonjour.
Je fais appelle a vous pour avoir vos opignons sur une stratégie sur la gestion des bases de données.
Actuellement, je suis en train de faire une application web pour une boutique générique gratuite. Etant donnée que c'est un milieu sensible j'ai pensé à une chose. Dans le cas ou un utilisateur a la main sur son serveur.
 
Dans la zone admin les types de bases utilisées qui peuvant être utilisées sont SQLServeur, Mysql5 (innoDb). Il y a une gestion des clés étrangère pour la fiabilité des informations.
Du coté admin il peut avoir des comptes Db pouvant écrire sur la base.
J'ai pensé donner la possibilité d'utiliser une autre base de données pour la zone public pour plusieurs raisons :
 

• Pour avoir un compte utilisateur n'ayant que acces en lecture sur la base de données public limitant ainsi les risques d'écritures dans la base public par un pirate.

• Dans le cas ou des collaborateurs travaillant sur des articles. Il ne puissent pas agire sur la zone public. Imaginez que quelqu'un confonde les centimes. Imaginez un serveur coutant 16 000€ il y a une erreur de saisie et marque 160.00 €. Imaginé qu'entre le moment ou c'est validé et le moment ils s'en rendent compte il y a déjà eu un payement parce qu'un coyote a reniflé l'affaire    . Vous allez me dire que ça peut se gérer par code mais pas envie, pas le temps, c'est la galère.    

La synchro entre les deux bases pourra se faire à heure fixe ou après validation par une personne. De plus pour des soucies de rapidité, les tables public sont en MyIsam car très rapide. Cette base ne sera qu'une image de l'instant T de la base admin donc pas besoin qu'il puisse y avoir une gestion de clés étrangère car les informations ne bougerons pas.
 
Pour résumé il y a deux bases. Une admin une public elles se synchronisent ou du moin l'admin écrase les données public.
Est-ce bête comme idée? Coté code j'ai quasi rien à faire c'est juste donner cette possibilité?

Salut.
 
Personnellement, je n'aime pas les notions de base de données de brouillon / base de données de travail.
En fait, pour moi peuvent exister différentes bases de données, avec les rôles suivants :
- Base de dev
- Base de test
- Base de recette
- Base de production
=> Les 4 bases sont identiques (dans la mesure où on n'est pas en train de faire de développement). Et leur rôle correspond uniquement aux phases de modification de l'application, et non des données
 
Mais aussi :
- Base de travail
- Base de reporting
=> La base de travail, c'est la base que tu utilises au jour le jour afin de gérer tes données.
=> La base de reporting est une base dédiée aux statistiques et autre rapports, synchronisée une fois par jour par exemple, dont le modèle est particulièrement adapté au reporting (données calculées stockées, etc.)
 
Par contre, avoir deux bases pour gérer la phase de vie des informations me semble une grosse erreur.
 
Imagine plutôt un flux de validation des données :
-> Une table "article_modification" dans laquelle tu clônes tout article à modifier, ou dans laquelle tu crées les nouveaux articles. Associée à une gestion de validation, cela te permet de travailler sur les données sans impacter celles qui sont disponibles dans la partie publique tant qu'elles n'ont pas été validées.
 
C'est le fonctionnement classique, quand il n'est pas simplement réduit à un flag dans la table "publique", mais à ce moment toute ligne en cours de modification est retirée de la partie publique tant qu'elle n'est pas validée, ce qui est donc plus adapté à de la création uniquement.
 
Ce système est d'ailleurs plus souple que celui que tu proposes, puisque tu comptes faire une validation "tout d'un coup", c'est à dire obliger les intervenants à stopper toute activité pendant la phase de validation, afin de pouvoir "pousser" en production toutes les informations modifiées. Avec ce que je préconise, tu n'as pas cette limitation, et tu "pousses" les éléments au fur et à mesure de leur validation.
 
Pour ce qui est des droits, je ne connais pas bien MySQL.
Pour SQL Server par contre, tu peux gérer les droits de façon très fine, un peu sur le modèle des droits sur la NTFS.
 
Ainsi, pour chaque objet de ta base, tu peux donner des droits spécifiques pour chaque utilisateur de la base de données.
Mieux, si un objet (vue, ps, trigger, etc.) dispose de droits suffisants pour être exécuté, il ne prendra pas en compte les éventuels droits explicites sur les objets utilisés.
 
Par exemple, tu as une table "user".
Dans cette table, tu as le champs "password". Donnée très sensible.
 
Tu peux alors faire un DENY sur tous les users.
Mais deux PS :
CheckLogin(login, pass) qui va rechercher l'id d'un user correspondant à ce login/pass, et faire un GANT pour tout le monde.
 
Si MySQL propose le même type de droits, alors je te conseille vivement de t'orienter vers ce type de gestion.
 
Sinon, pour ton histoire de clés étrangères... C'est pas parceque la base ne bouge pas qu'il ne faut pas de clés étrangères. Elles sont très utiles lors des jointures notamment !
http://forum.hardware.fr/hardwaref [...] 6416-1.htm

Merci pour ton intervention. Alors il y a un point que j'ai pas précisé :
C'est un application libre je ne connais pas la structure qui sera utilisé par l'utilisateur donc pas forcement de possibilité d'avoir plusieurs bases de données mais l'application pourra tourner soit sur une base ou sur plusieurs base, serveur sur différent type de SGBD cité plus haut. car il est divisé en zone autonome. Produit, CMS, Commande, Log, Utilisateurs.
 
Problème c'est que sur le projet je suis trop avancé pour faire une modification de structure.  
Tu as soulevé un point qui est important c'est qu'il n'est pas possible de valider cas par cas dans ce que je propose. J'avais une idée en tête qui était de gérer les informations dans un workflow c'est à dire que seul les éléments arrivé à leur terme peuvent être validé et donc visible. La notion de visible ou non est déjà intégré dans la structure. Problème c'est comment pouvoir éditer en admin un élément sans que la zone public puisse être touché. Pour remedier à cela j'ai donc pensé à un clone de la zone admin au public.
C'est pas forcé que ça soit que Mysql pour la zone public mais SQLServer ou PostGresql.
 
Concernant les droits, Mysql peut gérer les droits par tables comme dans SqlServer peut être avec moin de choses. Pour le compte public il aura que le droit SELECT mais comme toujours je ne donne que la possibilité d'avoir un autre compte à l'utilisateur de gérer les droits.  
Bien souvent les hebergeurs ne donne qu'un compte qui à tous les droits.

moi je persiste et signe : clône simplement ta table dans la base de travail, histoire de pouvoir bosser dessus sans toucher aux infos de la partie public. c'est moins lourd à faire, et plus permissif (notamment validation au cas par cas)

C'est à dire que je récupère l'information de la table public, je travaille dessus et ceux qui est dans cette table copie est en attente de validation pour être transféré sur la table public?
Si c'est cela ça ne me fait pas trop de modification.

oui c'est ça, et pas besoin de changer de base pour ça.

Je vais m'orienter sur cette stratégie plus simple.
Merci pour tes conseille

Une question parce que là quand je reprend le problème je vois qu'il y a un risque potentiel.
Simple exemple :  

• J'ai deux tables. Société et Employé.  
• Un employé est associé à une société.
• Je modifie une employé, donc il y a une copie de cette enregistrement dans une table prévus ayant la même structure et faisant toujour référence à la société.  

Que se passe t'il si cette société est aussi en cours d'édition par une autre personne lorsqu'il y aura la synchro a faire.  
Quel stratégie à adopter à ce moment là ?  
- Gérer les ordre de hiérarchie des informations ?
- Indiquer qu'il y a une des modifications sur l'une des références de l'enregistrement en cour ?
- Pas grave je balance la sauce.
- ???

Les règles sont à définir par tes soins mais, d'après mois :
-> Lorsque du modifie/crée un employé, tu dois être capable de voir sa société rattachée telle qu'elle existe "réellement", mais aussi l'éventuelle version en cours de modification, afin d'être sur que l'info reste cohérente.
-> Lorsque tu publies ton employé, tu offres la possibilité au validateur de publier en même temps la modification de la société, mais en aucun cas il faut rendre la chose automatique à mon sens.

Fonctionnellement c'est à toi de voir, mais personnellement le deuxieme point de MagicBuzz me semble le plus important...le premier est plus optionnel en fonction de tes besoins fonctionnels et si tu juges que c'est à la personne qui modifie ou à la personne qui valide de surveiller la cohérence des données.
 
Et techniquement, si la clé primaire de ta société n'est pas modifiable dans ta copie de travail, j'aurais tendance à dire tu balances la sauce, dans n'importe quel ordre, ça ne devrait pas poser de problème.

Je pense que le deuxième choix est la bonne. Même si je fais toujours référence à la même clé celui qui a modifier "employé" n'est peut être pas le même que celui qui a modifier la "société". Je pense que je devrais faire du cas par cas et non un système automatisé ou générique. Indiqué en plus entre la version en ligne et la version modifier.
 
Merci à vous deux