Discussion :

[selmagsi]

Salut les développeurs
J’ai un souci de sauvegarde de fichier dans une base de donnée postgrsql je ne sais pas comment le faire avec java,j’ai beau cherché et j’ai pas compris
Pour etre plus précise je veux sauvegarder des fichier pdf dans ma base de donnée sous pgAdminIII pour pouvoir ouvrir ces fichiers sous différentes machine sous un réseau local…
Je précise je veux sauvegarder le fichier et pas l’URL du fichier
Merci d’avance pour votre aide précieuse
Cordialement

[Cafeinoman]

Comment interfaces tu ta base et java? Les fichiers sont insérés manuellement ou par un programme java?

[selmagsi]

j'ai pas bien compris votre question je m'excuse
je me connecte à la base avec ces instructions:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
String query =null;
		     	ConnexionBaseDonnees connexion;
		String UrlBase = "jdbc:postgresql://192.168.1.1:5432/BDD";
 
                        String driver="org.postgresql.Driver";
			String user = "postgres";
			String MDP="****";

et les fichier seront sauvegardés par un programme java tout en passant par un JFileChooser

[wax78]

Ceci devrait t'aider et répondre a tes attentes http://ricky81.developpez.com/tutoriel/java/jdbc/blob/ (en remplacement "image" par pdf bien entendu puisque ca reste des données binaires).

[Gugelhupf]

Insérer des fichiers dans une base n'est pas une super idée je trouve. Autant garder les fichiers sur le disque et mettre une référence dans la base.

PS: pgAdminIII n'est pas la base, c'est une interface de gestion graphique administrateur. La "base" (ou plutôt SGBD) c'est PostgreSQL

[selmagsi]

Gugelhupf merci pour l'info ,puis je dois stocker le fichier dans la base pour pouvoir y accéder de n'importe quel machine (je suis sous une architecture client serveur ,un client doit pouvoir ouvrir un pdf quelque soit son emplacement réel)

wax78: je suis justemebt tombée sur un article du genre merci bcp de me l'avoir passé,j'essaye en tout cas avec et je passerai en résolu des que ça marche avec moi

[Gugelhupf]

Ce n'est pas une raison pour stocker un fichier dans un SGBD (et encore moins dans du PostgreSQL).

D'après ce que tu me dis je décèle un problème de sécurité lié à ton architecture, car ton SGBD accepte des requêtes venant de n'importe quelle machine. Si tu veux exposer des fichiers à travers le réseau tu peux utiliser service basé sur HTTP au lieu de JDBC.

[wax78]

Ce n'est pas une raison pour stocker un fichier dans un SGBD (et encore moins dans du PostgreSQL)..

Il est vrai que souvent pour certaines raisons il est déconseillé de faire un stockage de masse ainsi en database. Evidement c'est moins pratique pour coder car il faut garder les liens intègre de chaque cotés.

[Cafeinoman]

Ou alors il faut se tourner vers un truc orienté fichier comme JCR (Modeshape, Jackrabbit,...), du moins si tu as beaucoup de fichier à stocker.

[Gugelhupf]

Ou un DFS (Distributed File System) comme Hadoop (HDFS).

[selmagsi]

c'est simple mon application est installé sur plusieurs machine (clients) et la base est dans le serveur... si une machine A sauvegarde un fichier et que la machine B veut le voir elle peut le faire(c important) c'est pourquoi je dois stocker le fichier dans la base .... je galère en tous cas

[tchize_]

Ce qu'on essaie de te dire c'est qu'il n'est pas normal à la base que la machine A et la machine B aient accès direct à la base, pour des raisons de sécurité. Avec un accès direct à la base, l'utilisateur sur A peux joyeysement tapper un delete from taTable....
Ce qu'il faut c'est que tu développe une interface type web (REST) pour récupérer ces fichiers et les autres données et que dans cette interface, tu implémente ta sécurité, ce qui te permettra de donnée un login différent à chaque utilisateur.

[OButterlin]

ça me fait doucement rigoler, ça ne dérange personne que l'application A est accès aux données de la base mais ça dérange quand il s'agit de documents sauvegardés en DB

Personnellement, j'utilise très souvent la base de données pour sauvegarder des documents liés à des enregistrements (DB).
Le gros avantage, c'est qu'on peut utiliser l'intégrité référentielle pour gérer la suppression cascade de ces documents.
On n'a pas le souci d'un déplacement des fichiers sur le disque dur sans avoir pris la peine de modifier toutes les références dans les champs de la table qui les associe...
Bref, hormis un coût supérieur du stockage DB par rapport au stockage disque (avec de très gros volumes), il n'y presque que des avantages à utiliser une DB.

Ensuite, il faudrait savoir de quel type d'application il s'agit. C'est une application web ou un client java autonome (Swing) ?
La DB peut-être embarqué sur le PC client ou il s'agit forcément d'une connexion distante ?

Pour l'application web, dans tous les cas la connexion est gérée par le serveur d'application, il n'y a donc aucun problème de sécurité.
Pour une application autonome, à part en RMI, l'url de connexion est forcément exposée mais bon, à moins d'utiliser une compte / mot de passe générique, d'un point de vue sécurité, ça reste correcte.

Si la base de données est toujours distante, ça suppose que l'application ne fonctionne pas sans réseau. Donc, on pourrait imaginer partager les documents par un serveur dédié plutôt que la base (pour ceux que ça dérange )

[wax78]

Personnellement, j'utilise très souvent la base de données pour sauvegarder des documents liés à des enregistrements (DB).
Le gros avantage, c'est qu'on peut utiliser l'intégrité référentielle pour gérer la suppression cascade de ces documents.
On n'a pas le souci d'un déplacement des fichiers sur le disque dur sans avoir pris la peine de modifier toutes les références dans les champs de la table qui les associe...
Bref, hormis un coût supérieur du stockage DB par rapport au stockage disque (avec de très gros volumes), il n'y presque que des avantages à utiliser une DB.

Ouais ce que tu dis est parfaitement vrai. Mais dans certains cas, hébergeur de la DB fait des backup régulier et il n'aime pas trop les gros volume (véridique).

[OButterlin]

Ouais ce que tu dis est parfaitement vrai. Mais dans certains cas, hébergeur de la DB fait des backup régulier et il n'aime pas trop les gros volume (véridique).

Il est vrai qu'on peut avoir ce genre de contrainte externe, ou une limitation du volume DB aussi, mais c'est un autre problème.
Certes, il faut en tenir compte pour faire le choix d'architecture... mais dans l'absolu, hors contrainte externe, la DB est un excellent choix à mon avis.

[selmagsi]

ey les développeurs pourquoi vous me dites que mon application n'est pas sécurisé et que chaque machine a accés directe a la base? non une machine a ne peut effectuer aucun delete dans une table :o ,je ne pense pas avoir un pb de sécurité et j'ai bien défini les droit d'accés de chaque utilisateur... mais vous pouvez m'expliquer pourquoi vous dites que y a accés directe à la base ??

OButterlin vous me comprenez mieux que les autres mon application est un client java autonome ,elle est installés sur les different poste et la base se trouve dans le serveur ,on y accéde pour avoir les différents donnée y a t il des pb de sécurité?? puis je vais voir avec la technique dont vous avez parlé...

merci a vous tous de m'avoir donné de votre temps

[OButterlin]

mon application est un client java autonome ,elle est installés sur les different poste et la base se trouve dans le serveur ,on y accéde pour avoir les différents donnée y a t il des pb de sécurité??

Un problème de sécurité est toujours envisageable, ça dépend de ce qui a été mis en place.

Si par exemple chaque utilisateur utilise un profil / mot de passe qui lui est propre et que c'est ce compte qui est utilisé pour la base de données, il n'y a pas de problème particulier.

Si par contre, l'application embarque (dans un fichier de propriétés par exemple) le profil / mot de passe utilisé pour les connexions base de données, il y a un risque. Une personne mal intentionnée peut utiliser ces informations pour "pourrir" la DB voir la supprimer...

[selmagsi]

non pas de probléme de sécurité,mtn je vais enregistrer les fichier dans la base ,et je vois que ça se fait qu'avec le preparedStatement je trouve du mal a le comprendre ,mais ça va
merci pour votre aide

[tchize_]

Disons que la question qu'on peux se poser c'est comment tu gère, au niveau des sécurités de la DB, que l'utilisateur A peut supprimer la ligne X mais ne peux pas supprimer la ligne Y. Comment tu l'empeche de visionner une document auquel il n'est pas censé avoir accès. Comment tu gère l'audit pour savoir qui est l'andouille qui a posté 50 DVD dans la db? Pas avec postgresql en tout cas, la sécurité par row et toujours au stade de développement en cours chez eux.
C'est ça qu'on essaie de te faire comprendre. Il faut imaginer avec une application desktop qui accède directement à la base de données et l'utilisateur peux accéder directement à la base en contournant ton programme et donc seule les règles dans ton SGBD régissent ce que peuvent faire les utilisateurs. C'est parce que ce genre de sécurité est très dur à implémenter au niveau des SGBD (sauf peut être avec certains DBA haut de gamme) qu'en général on a recours à la gestion de cette sécurité à travers un webservice qu'on peux customizer aux petits oignons.

Voilà pour l'apparté. Pour le reste, si tu veux stocker un fichier, c'est dans un blob mais visiblement tu as déjà trouvé.


Obutterlin: je suis assez d'accord avec toi, je me pose en généra pas la question, ca part dans un blob comme ça tout est au même endroit. Mais il est vrai que ça plait pas aux DBA. Ca pose problème avec les transactions logs qui sont souvent limité en taille. (Faut déjà modifier des milliers de lignes avec une requete pour faire déborder un log de 1G, mais il suffit d'un blob de 2G pour le foutre en l'air), c'est la galère pour les backups incrémentiels et c'est une données non relationnel (on ne peux utiliser aucun opérateur relationnel sur un blob).

[OButterlin]

c'est une données non relationnel (on ne peux utiliser aucun opérateur relationnel sur un blob).

Que veux-tu dire par donnée non relationnelle ?

Nous utilisons une base DB2/400 et en fonction du type d'objet large défini, on a accès à plus ou moins de possibilités (BLOB, CLOB, DBCLOB).
Par exemple, une recherche sur le contenu de CLOB est tout à fait possible et même performante.

Pour les problématiques de sauvegarde, rien n'empêche de mettre les tables contenant les LOBs dans une bibliothèque séparée.

Maintenant, il y a des limites aussi, par exemple sur la taille du contenu... pour cette base, la limite est de 15Mo par LOB (il semble qu'une évolution à 2Gb soit envisagée).
Bref, en fonction des contraintes, il faut choisir la meilleure solution