Discussion :

[Hobbi1]

Bonjour,

Il a été décidé pour le projet sur lequel je bosse de stocker des fichiers XLS dans une colonne de type BLOB. La verison actuelle de la base est la 10.2.0.5, avec dans l'année une migration en 11g.

Les fichiers XLS vont servir à restituer des tableaux et des graphes. Comme les calculs seront assez lourds et longs, ils veulent tout pré-calculer dans des fichiers et les stocker en base.

J'avais plutôt proposer un stockage des fichiers sur un serveur dédié avec une colonne en VARCHAR ou BFILE car je pense que c'est plus efficace pour la base. Mais on m'a dit que ça n'était pas envisageable car trop lourd.

J'ai créé le sujet pour avoir des retours d'expérience, des avis, préconisations ou arguments.
J'espère donc que vous allez soit lever mes craintes, soit m'apporter des arguments infaillibles pour le projet.

Merci.

[Rei Ichido]

Je l'ai déjà fait sur un projet, ça ne pose pas vraiment de problème, sauf qu'il ne faut pas oublier que quand tu vas récupérer ton fichier, cela va transiter par ton appli (forcément, on ne peut pas juste donner un lien, par exemple) et donc qu'il va falloir tailler la mémoire allouable en fonction de la taille des fichiers et du nombre d'utilisateurs pouvant sauvegarder/demander de tels fichiers en parallèle.

[McM]

La différence BFILE vs BLOB, c'est que le BFILE ne stocke pas le fichier dans la base, mais sur le serveur. Donc il peut y avoir un problème de sécurité (n'importe qui ayant accès au serveur a accès aux fichiers).. et aussi de cohérence en cas de suppression manuelle des fichiers.
J'ai une base avec des blob (images), choix du blob pour la sécurité. Par contre on les a mis dans une seconde base pour un problème de sauvegarde et d'export, et ce choix n'était pas très judicieux, car les BLOB par dblink, c'est très restreint.

@Rei Ichido : Tu peux toujours accéder à tes fichiers dans un BLOB avec une URL avec modsql (je l'ai fait pour afficher des pdf), très pratique.

[Hobbi1]

Merci pour vos réponses.
Donc pour vous, le BLOB ne pose pas de problèmes particulier ?

Les utilisateurs ne feront que de la lecture. Ils iront juste chercher des fichiers contenant des tableaux d'indicateurs pré-calculés.
Les calculs seront fait par batch la nuit.

[Waldar]

Question bête peut-être, les calculs sont fait dans Oracle ou par d'autres mécanismes ?

Si vous avez une structure, plutôt que de stocker des BLOB ça vaut le coup de stocker des données relationnelles.

Recréer un fichier .csv exploitable par Excel depuis une table est relativement simple.

[Hobbi1]

Les calculs sont faits par batch et insérés dans Oracle.
Les tables contiennent les données à extraire directement.

L'IHM est en java et les utilisateurs passent par un explorateur.
L'architecte et les développeurs java ont dit qu'extraire les données directement de la base pour générer un XLS en dynamique à chaque demande des utilisateurs est impossible. Les fichiers contiennent beaucoup de lignes et beaucoup d'onglets et on m'a dit qu'il n'y aura jamais assez de mémoire.
Je dis ça juste pour infos car je n'y connais rien.

Les utilisateurs ont besoin de plusieurs onglets et veulent avoir une certaines présentations : couleurs, polices ...
Donc le csv est difficile.

[Rei Ichido]

On a donc fait face au même problème

Attention quand même au moment où les utilisateurs vont vouloir récupérer leurs fichiers, ça va passer par la jvm, et là ça peut faire mal si les xls sont volumineux et que plein d'utilisateurs le font en même temps (à tout hasard, vers la fin du mois quand ils commencent à récupérer les données pour faire leurs rapports).
Il va falloir, ou bien gérer du process de mise en file pour ne pas traiter plein de fichiers en parallèle, ou bien avoir une heap size conséquente pour la jvm !

[Hobbi1]

Ok
Merci pour l'info. Je vais en parler aux personnes concernées.