Discussion :

[VTT13]

Bj à tous

J'ai besoin de vos avis...
Il est prévu la réalisation d'un site WEBDEV avec des utilisateurs différents

A votre avis...

1 - Créer un répertoire pour chaque utilisateur
A chaque accès au site, s'identifier puis 'hchangerep' pour accéder aux données

2 - Ou fichiers communs avec une rubrique 'identifiant client'

//------------------------------------------------------------------
Le soucis c'est que je voudrais que chaque utilisateur effectue lui-même la sauvegarde de ses fichiers
a - On zipp
b - on telecharge
c - il renvoi dans son répertoire en cas de problème
Avec l'option1, cela devrait être possible

Avec l'option2, je ne vois pas comment faire
Une idée ?

Fichier natif FIC

[frenchsting]

Bonjour,

Si tu n'as pas de données communes et peu de volumétrie, les données peuvent être stockées dans le appdat de l'utilisateur.

Si tu as des données communes, alors, il va valoir séparer ce qui est commun de ce qui ne l'est pas. Dans ce cas, je préconise un serveur HF + une connexion locale aux fichiers utilisateur (hchangeconnexion).

[Ry_Yo]

Bonjour,

Pour moi, cela va dépendre de l'objectif de ce site web.
Si c'est un site du type CMS avec une page unique de login qui redirige sur un ensemble de page spécifique à cette utilisateur, en effet la solution de frenchsting est plus que recommandé afin de cloisonner au mieux les datas des différents utilisateurs
Si par contre ton site WebDev s'apparente à un forum ou équivalent, pas besoin de créer une BDD différente par utilisateur.

Donc en résumé, il te faut avoir une bonne vision de ton produit pour voir quelle solution est la mieux adapté à ton besoin.

Alors si on regarde les avantages/inconvénients :
Bases globale :
+ facilité de sortir des KPI de toutes sortes et de toute granularités
+ Pas besoin de gérer la connexion pour rerouter les requêtes sur la bonne BDD
+ une maj de l'analyse est "rapide"

- si une maintenance se fait sur la BDD, tous les utilisateurs sont impactés
- Une modification d'analyse peut prendre plusieurs dizaines de minutes (selon la volumétrie) avant que toutes les BDD soient ISO
- algo : ne pas oublié de filtrer correctement toute requête afin de ne pas afficher les informations d'un autre client
- les requêtes seront de plus en plus longue avec le temps


Bases spécifique pour chaque utilisateurs :
+ Si la base d'un client crash, les autres clients ne sont pas impactés
+ Sauvegarde/Restauration d'une BDD sans impacté l'ensemble des clients
+ algo : pas besoin de faire un filtre sur le client
+ les requêtes sont plus rapide sur le long terme car la taille des BDD dépendent du client

- pas de possibilité rapide de sortir des KPI, il faudra passer par des tables de consolidation ou faire des boucles pour ouvrir toutes les BDD
- pas de possibilité d'avoir un outil simple de gestion des comptes
- si une data est à modifier sur l'ensemble des clients, cette maj prendra plus de temps en fonction du nombre de BDD
- algo : jouer avec les indirections et alias pour capitaliser le code mais cela entraine une perte de lisibilité