bonjour cher journal,
Actuellement, je suis en cours de réflexion sur le système de gestion de permissions de mon application PhpWebGallery http://www.phpwebgallery.net(...) ou plutôt sur la façon dont j'ai codé ça...
Le système de permissions : chaque catégorie (N-niveaux possibles) peut-être soit publique, soit privée. Prenons cat1 par exemple, si elle est privée, alors elle devient inaccessible à tous les utilisateurs. Le seul moyen que l'utilisateur user1 puisse y accéder est que le webmestre l'y autorise directement (on dit alors que user1 est autorisée à visiter la catégorie privée cat1) ou bien que le webmestre autorise l'accès à un groupe auquel user1 appartient.
En fonction des restrictions d'accès, chaque utilisateur n'a pas les mêmes statistiques sur chacune des catégories (nombre d'images contenues en récursif, nombre de sous-catégories, date de la dernière image contenue en récursif, nombre total d'images sur l'ensemble de la galerie).
Voici comment j'ai codé ça de façon très technique :
- un champ status dans la table des catégories à "public" ou "private"
- une table user_access (contenant 2 champs : user_id et category_id), si une ligne est présente pour un couple {userX, categoryY}, alors userX a accès à la catégorie categoryY
- une table group_access sur le même principe (et évidemment, la table user_group existe)
Comme avec une galerie qui augmente rapidement, plus de 100 catégories, la création de la page peut avoir tendance à devenir très très long (plus d'1 seconde, voire pire sur un hébergement gratuit type free). J'ai mis en place des éléments calculés en base (c'est moche, je déteste ça, mais l'important c'est plutôt d'éviter de bouffer toutes les ressources sur un serveur mutualisé) :
- un champ forbidden_categories dans la table des users listant les catégories interdites, séparées par des virgules (pas taper, journal)
- une table user_category qui donne pour un couple {user,category} la date de la dernière image qu'on peut trouver dans la catégorie en cherchant récursivement et le nombre de sous-catégories directes (accessible à cet utilisateur)
Du coup, il faut que je mette à jour ces éléments calculés à chaque mise à jour de la base d'images, et ça peut devenir très très long (trop long à vrai dire) car, on aura vite fait le calcul : (nombre de lignes dans user_category) = (nombre de lignes dans users) * (nombre de lignes dans categories), et lorsque certains ont 1000 catégories et autant d'utilisateurs... la mise à jour plante lamentablement.
Bref, je cherche à améliorer la mécanique, pour que ça aille vite, quitte à limiter les possibilités ! Si ma question n'a pas sa place ici, merci de m'indiquer un lieu de discussion plus approprié :-)
# intéressant
Posté par Julien NOEL . Évalué à 1.
[^] # Re: intéressant
Posté par Pierrick Le Gall (site web personnel) . Évalué à 2.
Sache tout de même que PhpWebGallery est tout à fait du même type que Gallery, peut-être pas pour les mêmes personnes cependant, tout est une question de goût.
# Suggestions
Posté par _p4_ . Évalué à 1.
Sinon sur le principe chercher l'opération(s) qui ralenti ("en cherchant récursivement" par ex?) ton programme.
[^] # Re: Suggestions
Posté par Pierrick Le Gall (site web personnel) . Évalué à 2.
Finalement, le vrai problème, c'est que je veux afficher à côté de chaque catégorie dans le menu les 3 informations suivantes :
1. nombre d'images dans la catégorie
2. nombre de sous-catégorie
3. un marqueur dans le cas où il y aurait des images récentes trouvables en profondeur dans la catégorie
Pour les infos 2 et 3, je suis obligé d'avoir la table user_category pour ne pas recalculer tout à chaque fois. Je pense donc que je vais me passer de ces infos (qui sont sympas, mais pas indispensables du tout par rapport aux soucis qu'elles me posent), ce qui me permettra de ne plus avoir à maintenir une table user_category constituée uniquement dans le but d'affichage de ces infos.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.