Forum Programmation.SQL Stocker des photos dans une base de données

Posté par  .
Étiquettes : aucune
0
27
déc.
2007
Bonjour.

Est-il possible de stocker des photos dans un SGBD ?

En effet, j'ai lu des exemples de gestion ou de partages de photos, mais la plupart de ceux-ci ne stockent pas les images en BDD, mais seulement des URL vers lesdites images. Pourquoi?

Je vous remercie d'avance pour vos réponses.

  • # Je suis pas un expert, mais ...

    Posté par  . Évalué à 2.

    ... oui c'est possible, en utilisant un champ de type BLOB (ou assimilé). Ça permet de stocker n'importe que contenu binaire.

    Après, pourquoi ça ne se fait pas trop :
    - c'est plus compliqué à mettre en place
    - c'est plus lent quand la base est pas optimisée pour ça
    - ça fait très vite grossir la base
    - ...

    En gros, c'est pour mieux séparer deux "types" de contenus aux caractéristiques différentes : les images prennent de la place, les données assez peu ; les données sont lisibles par un humain, pas les images ; les données sont plus souvent accédées que l'image (supposition); etc ...

    Bref, je ne pense pas qu'il y ait de raisons complètement pertinentes, i.e. on trouve des partisans de l'un et de l'autre, c'est juste une question d'organisation.

    • [^] # Re: Je suis pas un expert, mais ...

      Posté par  . Évalué à 2.

      - c'est plus compliqué à mettre en place
      - c'est plus lent quand la base est pas optimisée pour ça

      Ces deux arguments me paraissent censés

      - ça fait très vite grossir la base

      Bah, que ce soit la base ou un FS qui grossit, quelle est la différence ? Seraient-ce des limites imposées par le SGBD ou l'OS (style taille de fichier maximum sur un FS, limitation sur la taille des tables dans le SGBD, etc ) ?
      De plus, je pense qu'il y a plus de risque de perdre de la place via les URL plutôt qu'en stockant les photos dans la base (moins de risque d'existence de photos n'ayant pas de lien vers l'appli - autrement dit des photos "orphelines").

      • [^] # Re: Je suis pas un expert, mais ...

        Posté par  . Évalué à 1.

        >Bah, que ce soit la base ou un FS qui grossit, quelle est la différence ?
        >Seraient-ce des limites imposées par le SGBD ou l'OS (style taille de fichier
        >maximum sur un FS, limitation sur la taille des tables dans le SGBD, etc ) ?

        Imagine que tu utilises un SGBD commercial célébre dans sa version gratuite. Dans ce cas, tu as des limites à la taille de la base gérée.

        Un autre argument en faveur du stockage en base, c'est les sauvegardes : tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement. Pas besoin de préciser à l'admin qu'il faut penser à sauvegarder tel répertoire en plus pour telle appli. Bref, en exploitation, c'est plus simple.

        • [^] # Re: Je suis pas un expert, mais ...

          Posté par  . Évalué à 2.

          Un autre argument en faveur du stockage en base, c'est les sauvegardes : tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement. Pas besoin de préciser à l'admin qu'il faut penser à sauvegarder tel répertoire en plus pour telle appli. Bref, en exploitation, c'est plus simple.


          mwais... tu présentes donc l'utilisation de la SGBD comme solution pour pallier à un éventuel problème de coordination avec l'administrateur... pas génial... En plus, faudra tout de même le prévenir de l'explosion de taille de ta base de données (ou alors tu vas te chopper des problèmes de quotas)... De toutes façons, si tu ne fait pas confiance à l'admin pour faire des backups de fichiers, tu devrais faire encore moins confiance pour les DB, a fortiori avec des blobs...

        • [^] # Re: Je suis pas un expert, mais ...

          Posté par  . Évalué à 1.

          tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement.

          ça se discute ... le souci, c'est qu'en cas de crash, tu vas restaurer chaque fichier corrompu de ta DB, quand bien même seul 5 % d'un fichier serait endommagé. Et un fichier de DB, ça peut devenir très gros, et restaurer un truc très gros, c'est trèèès long ... :/
          En conservant les photos sur le FS, si 5 % du FS est naze, tu ne restaures que ces 5 % là.

    • [^] # Re: Je suis pas un expert, mais ...

      Posté par  . Évalué à -1.


      c'est plus compliqué à mettre en place

      ça se discute. Je trouve l'approche "tout dans la base" assez simple. Une requête SQL, c'est quand même pas la mort.
      Et la possibilité, avec un simple backup de la base, de tout sauver, puis de tout restaurer, c'est appréciable.

      Par contre, ça implique d'accéder à ces fichiers en passant par la base.


      c'est plus lent quand la base est pas optimisée pour ça

      Je vais parler de ce que je connais : PostgreSQL. Ça ne sera pas le cas, meme si le champ BLOB est dans la même table que des champs de description.


      ça fait très vite grossir la base

      toujours pour PostgreSQL, ça ne prendra pas plus de place que si les fichiers sont stockés sur le disque dur. (en fait ça peut en prendre moins si on active la compression des champs binaires).

      Sinon j'ai lu un peu le thread, et je n'ai pas vu l'argument clé en la faveur d'un stockage dans le SGBD, à savoir l'intégrité référentielle.
      Si l'ajout d'un fichier échoue, on fait un simple rollback de la transaction et le tour est joué. Si le stockage est dans le filesystem, la gestion d'erreur devient plus complexe.

      Néanmoins, tout ça est une question de point de vue. Si tu n'es pas allergique à l'anglais :
      http://archives.postgresql.org/pgsql-general/2007-04/msg0019(...)
      : y sont développés quelques arguments intéressants.

  • # Raison pragmatique de ne pas le faire...

    Posté par  . Évalué à 2.

    Pour accéder à tes images, tu dois impérativement les réextraire de la DB, alors que si elles sont stockées sur le disque sous forme de fichiers, tu peux directement les ouvrir avec n'importe quelle application.

    Les images dans un SGBD, c'est rajouter une couche de complexité pour pas grand-chose.

    Par contre, indexer les images dans un sgbd, ça, ça a un sens (tu ne mets pas les images dans la db, juste les méta données, genre headers exif si ce sont des photos).

    • [^] # Re: Raison pragmatique de ne pas le faire...

      Posté par  . Évalué à 1.

      +1

      J'aurais moins bien dit :-)

    • [^] # Re: Raison pragmatique de ne pas le faire...

      Posté par  . Évalué à 2.

      et dans le cas ou tu veux gérer des droits d'accesa ax photos ?

      Il suffit que quelqu'un ait l'URL de laphoto pour pouvoir y accéder, non ?

      • [^] # Re: Raison pragmatique de ne pas le faire...

        Posté par  . Évalué à 1.

        dans ce cas-là, il suffit de ne pas laisser les photos directement accessibles et d'utiliser un script, qui lui aura accès aux images, pour effectuer la vérification des droits (dans la db par ex) et transmettre ou non l'image.

        Pour un serveur web, on peut donc simplement stocker les images en dehors du document root.

      • [^] # Re: Raison pragmatique de ne pas le faire...

        Posté par  . Évalué à 2.

        et dans le cas ou tu veux gérer des droits d'accesa ax photos ?


        tu peux parfaitement avoir tes photos dans un répertoire non accessible directement et avoir un script ou cgi les envoyant au client quand nécessaire, après vérification des droits, de la même manière que tu aurais fait ça en les stockant dans des blobs, mais en plus simple.

        • [^] # Re: Raison pragmatique de ne pas le faire...

          Posté par  . Évalué à 2.

          mouais, pas convaincu, étant donné que le serveur www tourne avec un ID ayant les droits pour accéder au répertoire en question une URL bien formée devrait permettre a quelqu'un d'accéder aux photos ... a moins de pouvoir l'empêcher au niveau du serveur www (peut-être dans la configuration apache ) , je vois pas trop comment faire ... Cela dit, côté base de données, c'est pas forcément mieux, sauf que pour accéder au blob, il faut obligatoirement passer par une requete sql, donc par une requete au serveur www via CGI ou script .... a moins que j'ai raté quelque chose (ca fait longremps que je n'ai pas touché a ce genre de truc).

          • [^] # Re: Raison pragmatique de ne pas le faire...

            Posté par  . Évalué à 2.

            a moins de pouvoir l'empêcher au niveau du serveur www (peut-être dans la configuration apache )

            Ça se fait en 2s en ajoutant un .htaccess dans le répertoire, et en mettant l'accès à "deny". Tes clients ne peuvent plus y accéder, mais tes scripts PHP ou autre, pas de problème. Comme ça, tu as un script qui sera appelé avec en paramètre le nom de ta photo, il vérifie l'accès et renvoie les données de l'image avec le type mime qu'il faut.

          • [^] # Re: Raison pragmatique de ne pas le faire...

            Posté par  . Évalué à 2.

            Cela dit, côté base de données, c'est pas forcément mieux, sauf que pour accéder au blob, il faut obligatoirement passer par une requete sql, donc par une requete au serveur www via CGI ou script


            si un hacker arrive à contourner la sécurité apache pour récupérer des fichiers protégés correctement par un .htaccess ou placés hors de la racine du serveur web, je ne vois pas pourquoi il n'arriverait pas à récupérer tes requêtes...

            • [^] # Re: Raison pragmatique de ne pas le faire...

              Posté par  . Évalué à 2.

              si un hacker arrive à contourner la sécurité apache pour récupérer des fichiers protégés correctement par un .htaccess

              euh .... relis bien l'enchainement des réposes. Il n'était pas question d'un fichier .htaccess a ce stade de la discussion ... ce n'est venu que dans la réponse suivante.

              • [^] # Re: Raison pragmatique de ne pas le faire...

                Posté par  . Évalué à 2.

                Et?

                Le problème principal de cette discussion est qu'au lieu de venir avec ton problème, tu es venu avec une solution, celle de la DB, sans même avoir creusé les possibilités de sécurité au niveau de l'application serveur web. Tu n'as même pas formulé une seule fois ce que tu voulais exactement faire.

                • [^] # Re: Raison pragmatique de ne pas le faire...

                  Posté par  . Évalué à 1.

                  Un peu tard mais ....
                  au lieu de venir avec ton problème,
                  Je n'ai pas de problème ...

                  tu es venu avec une solution, celle de la DB
                  oui

                  Tu n'as même pas formulé une seule fois ce que tu voulais exactement faire.
                  Je ne le sais pas moi-même et c'est pour ça que je pose des questions, pour avoir des pistes.

                  En gros, je veux pouvoir stocker des photos quelque part (en base ou dans un répertoire, peu importe), et gérer des droits d'accès à ces photos. Je n'ai que rartement vu un stockage de photos en BDD et j'essaie de comprendre pourquoi. Et effectivement je me met "dans a peau" d'un pro BDD (sans en etre réellement un, je cherche juste à comprendre). Pour le moment j'ai pas pris de décision (pas eu le temps de tester les deux approches), mais dès que j'aurai un peu de temps je le ferai et je m'orienterai certainement vers la solution "ficiers platsavec indesx en BDD". Mais au moins je saurai pourquoi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.