Journal album photo en ligne, gestion des permissions, besoin de conseils avisés

Posté par  (site web personnel) .
Étiquettes : aucune
0
20
mai
2004
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  . Évalué à 1.

    j'intégre un lien dans mon document(http://linuxfr.org/2004/05/18/16262.html(...)), ok ?
    • [^] # Re: intéressant

      Posté par  (site web personnel) . Évalué à 2.

      pas de problème, ton document est très intéressant, je l'ai mis en pratique toute mon après-midi d'hier en renommant mes fichiers et en me créant une arborescence de type {année}/{numero_mois-libellé_mois}. Heureusement que depuis que je suis sous Linux (avant sous Microsoft Windows, j'utilisais un logiciel propriétaire pour récupérer mes photos), les photos récupérées sur mon APN ne perdent plus les métadonnées, sur 2003/2004, ça m'a permis d'aller nettement plus vite en utilisant l'info "Capture Date".

      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  . Évalué à 1.

    Pourquoi tu crée pas plutôt dans ta table categories des champs avec comme infos dedans les paramètres d'accès pour les users et groupes (genre des champs authorised_users et authorised_groups), plus d'autres infos si besoin (genre date de la dernière image) ? Ca fait déjà moins d'accès base à chaque fois.

    Sinon sur le principe chercher l'opération(s) qui ralenti ("en cherchant récursivement" par ex?) ton programme.
    • [^] # Re: Suggestions

      Posté par  (site web personnel) . Évalué à 2.

      c'est une idée, on déplace les infos users.forbidden_categories dans categories.forbidden_users (ou authorized, ça revient au même).

      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.