Discussion :

[ghozlane19]

Bonjour

Je suis sur un projet ou je dois faire l'acquisition et traitement d'images pour tirer le max d'informations et les stocker dans une base de données.
J'ai débuté avec le SQLite qui m'a permis de créer des tables, après quelques essais je veux maintenant insérer les images dans cette base de données.

Est-ce qu'il faut mettre le chemin du répertoire d'image seulement ? ou alors comment faire ?
Comment est la syntaxe de programmation je travail en C.

Merci d'avance !

[CinePhil]

C'est une mauvaise idée de stocker les images dans la BDD !

[StringBuilder]

Cet article de 2003 est complètement dépassé et mérite d'être totalement réécrit.

- Sous SQL Server par exemple, il est parfaitement possible de développer des filtres compatibles avec le moteur FULL TEXT pour extraire et indexer les meta des images, ou même, comme je l'avais fait pour m'amuser, récupérer par OCR le texte contenu dans l'image : une image est donc une donnée comme une autre, qu'on peut interroger, utiliser pour des statistiques, etc.
- Sous SQL Server, mais ce n'est pas le seul, il existe des formats dédiés au stockage des fichiers (texte, binaires, images) de façon extrêmement performante (FILESTREAM, FILETABLE, etc.)
- L'avantage de stocker les images (ou autres fichiers) dans la base, c'est qu'une sauvegarde de cette dernière (à chaud c'est possible) sauvegarde aussi les fichiers référencés. Il est impossible de synchroniser les sauvegardes du système de fichier et de la base sans devoir arrêter l'application.
- Le second avantage, c'est qu'on peut gérer les modifications des fichiers de manière transactionnelle, au même titre que les données : on évite alors les fichiers référencés nulle part, et les références vers des fichiers inexistants, ou même pire, ne correspondant pas du tout à ce qu'on référence.

SQLite est un SGBD assez pauvre, et les deux premiers arguments ne sont pas forcément valables.
Mais pouvoir gérer les modifications des images sous forme de transactions, et de garantir qu'une sauvegarde permet de repartir d'un état cohérent des données (images et données y faisant référence) sont suffisant à eux seuls pour rendre caduque l'article cité plus haut.

[ghozlane19]

Cet article de 2003 est complètement dépassé et mérite d'être totalement réécrit.

- Sous SQL Server par exemple, il est parfaitement possible de développer des filtres compatibles avec le moteur FULL TEXT pour extraire et indexer les meta des images, ou même, comme je l'avais fait pour m'amuser, récupérer par OCR le texte contenu dans l'image : une image est donc une donnée comme une autre, qu'on peut interroger, utiliser pour des statistiques, etc.
- Sous SQL Server, mais ce n'est pas le seul, il existe des formats dédiés au stockage des fichiers (texte, binaires, images) de façon extrêmement performante (FILESTREAM, FILETABLE, etc.).

Merci pour votre réponse sur ce projet mon tuteur exige de travailler avec le SQLite car pour le traitement d'image en code C est développer sous un logiciel imposer aussi donc dans mon cas je veux juste enregistrer les images brute acquises dans la base de donner dans le compilateur C de ce logiciel (ps j'utilise LabwindowsCVI), j'ai pensé aussi à convertir l'image sous forme de table binaire et la stocker mais je ne sais pas si c'est faisable je ne suis pas informaticienne je ne maitrise que les bases

[StringBuilder]

En fait, tu dois te poser plusieurs questions avant de décider de stocker les images sous forme de BLOB ou simplement leur chemin d'accès.

1/ Des applications externes doivent-elles pouvoir accéder et modifier les images ?
- Si oui, alors le BLOB ne le permet pas. En revanche, attention aux images référencées "Ballon rouge" dans la base, et écrasées par un chien jaune dans une application externe !
- Si non, alors le BLOB permet de garantir qu'aucune application externe ne va venir altérer les images

2/ Les informations tirées des images sont-elles figées ? Les images elles-mêmes sont-elles figées ?
- Si oui, alors le stockage en BLOB n'a pas de grand intérêt du moment que tu peux garantir qu'aucune application externe ne va les modifier (par une gestion appropriée des droits par exemple)
- Si non, alors il faut pouvoir garantir la cohérence entre les données relatives à l'image et l'image elle-même : le BLOB est donc tout désigné

3/ Le volume des images est-il important ? (plus de 1 Go par exemple)
- Si oui, alors cela peut s'avérer problématique en termes de performances. Il faudra créer une table dédiée aux images de façon à séparer au maximum les données "vivantes" de la base des données des images. Le BLOB peut s'avérer problématique à terme
- Si non, alors le BLOB ne pénalisera pas les performances. Et même au contraire, en une seule lecture logique, on pourra accéder aux informations des images et à leur contenu : ceci peut être bénéfique en termes de performances (moins d'accès concurrents sur le disque, surtout si tout est sur le même disque)

Voici un exemple de stockage de BLOB dans SQLite avec C++ :
https://stackoverflow.com/questions/...ob-insertion-c

[ghozlane19]

1/ Des applications externes doivent-elles pouvoir accéder et modifier les images ?

2/ Les informations tirées des images sont-elles figées ? Les images elles-mêmes sont-elles figées ?

3/ Le volume des images est-il important ? (plus de 1 Go par exemple).

Merci pour le lien , pour répondre aux questions
1. les images ne seront pas modifier utilisées juste pour tirées des informations , 2. oui une fois l'image est acquise elle est enregisté dans un fichier et ne change pas ni d'emplacement ni de caractéristiques ,3. par contre le volume d'images est à tres grandes résolution oui

[tsuji]

C'est vrai qu'on est beaucoup liberé au fil du temps de ceci et cela : bdd n'est pas désignée pour xxx, xml n'est pas désigné pour yyy, langage zzz n'est pas désigné pour processus temps réel, téchnologie aaa est verbeuse, langage bbb est vilaine ... le problème éventuel n'est que ce ne soit même pas faux, le problème est que ça devient un carcan du raisonnement raisonné ou de la raison tout court.

Voici des idées avancées et défendues par M Kratochvil du coté Oracle:
http://download.oracle.com/otndocs/p...multimedia.pdf
et son livre
Marcelle Kratochvil, Managing Multimedia and Unstructured Data in the Oracle Database, Packt Publishing; 2013.

[SQLpro]

Microsoft à fait un boulot largement supérieur aux BFIle d'Oracle avec le FILESTREAM, car, comme il est mono plateforme et que c'est du Windows (les fichiers pouvant être "hooké" sur windows, mais pas sur Linux) c'est plus sûr...
Et le FILESTREAM a été étendu au FILETABLE...

mais bon, c'est pas demain qu'on verra cela dans SQLlite !

A +

[ghozlane19]

mais bon, c'est pas demain qu'on verra cela dans SQLlite !

A +

Bonjour,
est ce que cela veux dire qu'en SQLite, le stockage et manipulation d'images n'est pas possible!

[StringBuilder]

Si, c'est possible, mais les contraintes énoncées dans l'article datant de 2003 s'appliquent toujours.

Au vu des réponses que tu as donné, alors le stockage des images sous forme de BLOB ne semble pas opportun, car tu n'en tireras aucun avantage, uniquement des inconvénients (ou presque).

[ghozlane19]

Si, c'est possible, mais les contraintes énoncées dans l'article datant de 2003 s'appliquent toujours.

Au vu des réponses que tu as donné, alors le stockage des images sous forme de BLOB ne semble pas opportun, car tu n'en tireras aucun avantage, uniquement des inconvénients (ou presque).

Alors pour ce genre de problème tu pense que c'est mieux de stocker juste le chemin ou se trouve mes images ?

[CinePhil]

Alors pour ce genre de problème tu pense que c'est mieux de stocker juste le chemin ou se trouve mes images ?

Oui. C'est ce que préconise l'article de SQLPro, écrit peut-être avant que SQL Server n'implémente les FILESTREAM.
Avec SQLLite ou MySQL (et peut-être PostgreSQL, je n'ai pas vérifié), le filestream n'existant pas, c'est bien ça qu'il faut faire.

[genemartin]

Puisque vous semblez l'ignorer, il y a très longtemps que le monde de la géomatique permet l'intégration des fichiers images dans SQLite, avec profit, je le souligne

- http://www.gdal.org/frmt_rasterlite.html
- http://www.gdal.org/frmt_rasterlite2.html
- https://www.gaia-gis.it/fossil/librasterlite/index
- http://erouault.blogspot.com/2014/12...r-support.html
- https://pro.arcgis.com/fr/pro-app/to...geopackage.htm
- etc.

[SQLpro]

Puisque vous semblez l'ignorer, il y a très longtemps que le monde de la géomatique permet l'intégration des fichiers images dans SQLite, avec profit, je le souligne

SQL Lite ne stocke par les fichiers. Il stocke le contenu binaire des fichiers... Comme la plupart des SGBD car il suffit de disposer d'une type binaire pour ce faire...

La question n'était donc pas celle-ci, mais la question était de savoir s'il est opportun de stocker les binaires (appelées BLOBs dans les GBDR) résultant des fichiers dans une colonne de la table ou bien de les laisser en tant que fichiers en ne stockant dans la table que le chemin du fichier.

L'inconvénient de stocker des BLObs dans une base, surtout si elle ne gère pas des espaces de stockage différents en séparant données purement relationnelles des BLOBs est la question des performances...
En effet si je dois faire une requête ressortant les id et date des photos, la lecture des pages sera augmenté par la quantité des octets du binaire des fichiers et le temps d'exécution s'en ressentira.
C'est pourquoi dans les grands SGBDR on propose différentes solutions :

• stocker les LOBS dans les tables dans un espace de stockage dédié (directive TEXTIMAGE_ON dans SQL Server par exemple) afin de ne pas mélanger IO relationnels et IO binaires
• ou bien stocker les images sous forme de fichier, mais contrôlé par le serveur SQL (transactionnement, autorisations, anonymisation...). Principe du BFile d'Oracle ou du FILESTREAM de SQL Server

Malheureusement dans mySQL, PostGreSQL et à fortiori SSLLite aucune des deux solutions n'existent !

A +