data dans une base

Bon ma question manque un peu de clareté.
je suis sous postgres...
et j'aimerai bien savoir s'il y a une raison pour ne pas balancer des
fichier binaire dans une base de donnée...

dans ce cas faut il utiliser le type bytea
ou les larges objets?

voila.
merci.
Etienne

Etienne SOBOLE a questionné:

salut.
est une bonne idée de suaver des fichier dans une base de donnée...
en fait la question est surtout:
y a t il une raison de ne pas le faire?

merci
Etienne

Bonsoir,

Cet article de Frédéric Brouard traite des images qui ne sont que des fichiers
binaires particuliers. Mais il te permettra , j'en suis sur de faire une opinion
valable sur le sujet et en tirer les conséquences... ;-)

http://sqlpro.developpez.com/cours/stockerimages/

AMHA, la réponse à ta question est non ! :-)
Par contre, gérer dans ta base de données des informations (mots clés,
indexation textuelle, etc) permettant d'accéder à ces fichiers par des
recherches me semble nettement plus pertinent...

--
Philippe.

Cet article de Frédéric Brouard traite des images qui ne sont que des
fichiers binaires particuliers. Mais il te permettra , j'en suis sur de
faire une opinion valable sur le sujet et en tirer les conséquences...
;-)

Oui biensur que j'ai pensé a cette solution, mais il se trouve que parfois
la réalité est un peu plus complexe...
Exemple...

je veux stoker un document de type quelconque (image, pdf, word, voir meme
un ensemble de document commun une page web avec ses images)...
alors l'utilisation du file system pour stoker ces informations n'est pas
forcement le meilleur choix !

- lors du backup de la base, rien ne garantit que le backup des fichiers du
serveur sont réalisés en meme temps !
- une page html peut etre composée de la page elle meme et de 5 images dans
ce cas, on fait quoi ??? avec une base je crée un tableau et je balance
dedans tous les fichiers, c'est ce tableau par la suite que je donne a la
base... (un peu comme un mail finalement)

L'article de Frederic précise que cela nuit a la performance de la base,
c'est surtout ca qui m'inquiete...
Etienne

Etienne SOBOLE wrote:

Cet article de Frédéric Brouard traite des images qui ne sont que des
fichiers binaires particuliers. Mais il te permettra , j'en suis sur de
faire une opinion valable sur le sujet et en tirer les conséquences...
;-)

Oui biensur que j'ai pensé a cette solution, mais il se trouve que parfois
la réalité est un peu plus complexe...

La réalité est toujours plus complexe... ;-)

Exemple...

je veux stoker un document de type quelconque (image, pdf, word, voir meme
un ensemble de document commun une page web avec ses images)...
alors l'utilisation du file system pour stoker ces informations n'est pas
forcement le meilleur choix !

C'est pourtant à cela qu'est destiné un filesystem: gérer des fichiers de tout
type... avec des droits de gestion paramétrables...

- lors du backup de la base, rien ne garantit que le backup des fichiers du
serveur sont réalisés en meme temps !

Un backup du SGBD ne se limite qu'au SGBD et ne se substitue pas (ni même ne
dispense d'ailleurs) d'avoir une sauvegarde sur bandes des données (au sens plus
global du terme) du serveur !

- une page html peut etre composée de la page elle meme et de 5 images dans
ce cas, on fait quoi ??? avec une base je crée un tableau et je balance
dedans tous les fichiers, c'est ce tableau par la suite que je donne a la
base... (un peu comme un mail finalement)

Eh bien concevoir un modèle de base adapté au référencement de ces fichiers et à
leur accès d'une part et un ou des emplacements de stockage dédiés avec des
droits de gestion idoines d'autre part. Le SGBD contient alors toutes les
informations utiles à une indexation et des mécanismes de recherches de ces
fichiers, à un accès à ceux ci; le filesystem gérant lui le stockage...

L'article de Frederic précise que cela nuit a la performance de la base,

Embarquer dans une base des données que l'on ne peut "malaxer" est effectivement
pénalisant. Le SGBD se limite alors à un "bête" outil de stockage; autant
laisser cette tache à un outil dont c'est la tahce première...

c'est surtout ca qui m'inquiete...

Surtout si le SGBD a tendance à monter en memoire ces informations. On peut très
vite consommer des ressources performantes, solliciter des échanges disques
mémoire fréquents et donc faire chuter significativement les performances.

Etienne

--
Philippe.

Un backup du SGBD ne se limite qu'au SGBD et ne se substitue pas (ni même
ne dispense d'ailleurs) d'avoir une sauvegarde sur bandes des données (au
sens plus global du terme) du serveur !

Ce que je voulais dire c'est qu'un backup de SGBD est normalement
transactionnel.
si tu backup d'un coté la base et de l'autre le serveur avec les fichiers
qui sont référencés dans la base ca commence a devenir critique...

Eh bien concevoir un modèle de base adapté au référencement de ces
fichiers et à leur accès d'une part et un ou des emplacements de stockage
dédiés avec des droits de gestion idoines d'autre part. Le SGBD contient
alors toutes les informations utiles à une indexation et des mécanismes de
recherches de ces fichiers, à un accès à ceux ci; le filesystem gérant lui
le stockage...

En fait mon probleme n'est pas une question de référencement ni meme
d'idexation, mais de sécurité des données...

Surtout si le SGBD a tendance à monter en memoire ces informations. On
peut très vite consommer des ressources performantes, solliciter des
échanges disques mémoire fréquents et donc faire chuter significativement
les performances.

Hum oui, c'est vrai. J'y avais pas pensé. Il faut espérer que les caches
sont suffisamanent malin pour ne pas cacher les grosses données...
surtout que pour ne pas utiliser le bytea (qui n'extsite sans doute pas
ailleurs) j'ai préférer rester avec des bons vieux champ text, et donc
convertir en base64 mes fichiers avant de les sauver dans la base de donnée.

tout un programme ;)

Etienne SOBOLE a dit le 24/01/2005 19:54:

- une page html peut etre composée de la page elle meme et de 5 images dans
ce cas, on fait quoi ??? avec une base je crée un tableau et je balance
dedans tous les fichiers, c'est ce tableau par la suite que je donne a la
base... (un peu comme un mail finalement)

Rien ne t'empêche de stocker un tableau de fichiers sur le système de
fichiers, de la même façon que sur une base de données.

Rien ne t'empêche de stocker un tableau de fichiers sur le système de
fichiers, de la même façon que sur une base de données.

Non, mais en fait, je crois que je me suis un peu égaré pour expliquer ce
que je cherche a faire...
Il est certain que je peux ne pas utiliser les based de données (puisque de
toute façon j'ai n'ai pas du tout l'intention de faire une recherche dans
les fichiers...)

L'idée d'utiliser une base de données, c'est:
- De pouvoir utiliser les transactions (ce que je peux simuler avec des
semaphores on est d'accord)...
- Garantir qu'en cas de probleme on ne perd aucune donnée, et la, je suis
désolé, mais je n'ai pas encore trouvé comment backuper la base et les
fichiers en meme temps garantissant ainsi que les chemins des fichiers
correspondent bel et bien a des fichiers physique.
- Au niveau sécurité (puisqu'il s'agit d'une application WEB), il est
toujours plus simple d'aller récuperer un fichier sur un serveur plutot
qu'un information dans une base de donnée!!!
- Enfin et c'est pas l'un des moins, la gestion par fichier risque souvent
(pas toujours) de laisser trainer quelques fichiers sur le HD qui n'ont plus
de raison. pour une raison x ou y on supprimer un enregistrement, on oublie
deffacer le fichier et voila...

Bref, ma question n'est pas de savoir si on peut faire autrement, mais
plutot de savoir s'il y a une raison de ne pas enregistrer les fichiers dans
la base !

Etienne

Bonjour,

le problème serait résolu si tu utilisait IBM DB2. En effet, c'est le seul SGBDR
à répondre aujourd'hui à cette double roblématique : externaliser les données
fichiers et intégrer un mécanisme d'intégrité référentielle et de sauvegarde gobale.
C'est d'ailleurs ce qu'à prévu la norme SQL:1999, avec le DATALINK :

Voici ce que je dit dans un livre à paraître cet été :
"
2.5.8 Datalink
Le type DATALINK est une référence à un fichier externe, permettant par exemple
de stocker des images, de la vidéo, des sons et des fichiers binaires. Les
fichiers ainsi référencés restent sur un disque quelconque du système
informatique. Les données sont donc externe à la base, mais il est possible de
maintenir une intégrité de manière à interdire modifications et suppression des
fichiers autrement que par un ordre SQL de la base.
Un tel type de données se déclare de la sorte :
DATALINK [ <options_de_contrôle> ]

<options_de_contrôle> :: NO LINK CONTROL | FILE LINK CONTROL <option_de_contrôle_fichier>

<option_de_contrôle_fichier> :: <option_intégrité> <autorisation_lecture> <autorisation_écriture>
<option_récupération> [ <option_détachement> ]

<option_intégrité> :: INTEGRITY ALL
| INTEGRITY SELECTIVE
| INTEGRITY NONE

<autorisation_lecture> :: READ PERMISSION FS
| READ PERMISSION DB

<autorisation_écriture> :: WRITE PERMISSION FS
| WRITE PERMISSION BLOCKED

<option_récupération> :: RECOVERY NO
| RECOVERY YES

<option_détachement> :: ON UNLINK RESTORE
| ON UNLINK DELETE
| ON UNLINK NONE

NO LINK CONTROL signifie que les liens ne sont connus par la base que par leurs
noms (URI : Uniform Ressource Identifier). Dans le cas contraire, FILE LINK
CONTROL, il est possible de piloter les liens par les options de la base de
données décrites ci dessous :
INTEGRITY ALL : seul un ordre SQL peut supprimer ou modifier les fichiers
afférant au lien.
INTEGRITY SELECTIVE : un ordre SQL, comme le système de fichier de l'OS peut
supprimer ou modifier les fichiers afférant au lien.
INTEGRITY NONE : seul le système de fichier de l'OS peut supprimer ou modifier
les fichiers afférant au lien.
READ PERMISSION FS : les droits en lecture sont définis par le système de fichiers.
READ PERMISSION DB : les droits en lecture sont définis par la base de données.
WRITE PERMISSION FS : les droits en écriture sont définis par le système de
fichiers.
WRITE PERMISSION BLOCKED : aucun droit en écriture n'est autorisé.
RECOVERY YES : sauvegarde et restauration possible dans le cadre de la base de
données.
RECOVERY NO : sauvegarde et restauration impossible dans le cadre de la base de
données.
ON UNLINK RESTORE : restaure les droits et propriétaire système originels si le
lien est détaché de la base.
ON UNLINK DELETE : suppression le fichier en cas de détachement de la base.
ON UNLINK NONE : en cas de détachement de la base, le fichier n'est pas supprimé
et les droits restent pendants (des droits système sont appliqués par défaut si
cela est possible).

Exemple :
CREATE TABLE T_FILM_FLM
(FLM_ID INT NOT NULL PRIMARY KEY,
FLM_TITRE VARCHAR(256),
FLM_FILM DATALINK FILE LINK CONTROL
INTEGRITY ALL
READ PERMISSION DB
WRITE PERMISION BLOCKED
RECOVERY YES
ON UNLINK NONE,
FLM_ANNEE INT)
SQL:1999 fournit en outre des fonctions afin de piloter l'insertion, la
restitution, comme l'extraction de certaines parties de l'URI :
DLVALUE : instancie la valeur de l'URI pour la colonne de type DATALINK
(constructeur).
DLURLCOMPLETE : restitue la valeur de l'URI contenu dans la colonne de type
DATALINK.
DLURLPATH : restitue le chemin de l'URI, avec son origine.
DLURLPATHONLY : restitue le chemin, de l'URI, sans son origine.
DLURLSCHEME : restitue le mode de flux (http ou file) de l'URI.
DLURLSERVER : restitue la ressource de l'URI.



Exemple :
INSERT INTO T_FILM_FLM (FLM_ID, FLM_TITRE, FLM_FILM, FLM_ANNEE)
VALUES (178, 'West Side Story',
DLVALUE('file://srvmed/films/WesSideStory.mpeg'),
1960)
insère une ligne dans la table T_FILM_FLM avec la référence au fichier vidéo du
film "West Side Story".
SELECT FLM_TITRE, FML_ANNEE, DRURLCOMPLETE(FLM_FILM) AS FLM_MPEG
FROM T_FILM_FLM
WHERE FLM_ID = 178

FLM_TITRE FML_ANNEE FLM_MPEG
----------------- ------------ ---------------------------------------
West Side Story 1960 file://srvmed/films/WesSideStory.mpeg
"

Rien ne t'empêche de t'inspirer de la chose pour créer un mécanisme similaire.
Tout dépend de la base de données que tu utilise : a t-elle accès à l'OS via des
SP ?

A +



Etienne SOBOLE a écrit:

Rien ne t'empêche de stocker un tableau de fichiers sur le système de
fichiers, de la même façon que sur une base de données.

Non, mais en fait, je crois que je me suis un peu égaré pour expliquer ce
que je cherche a faire...
Il est certain que je peux ne pas utiliser les based de données (puisque de
toute façon j'ai n'ai pas du tout l'intention de faire une recherche dans
les fichiers...)

L'idée d'utiliser une base de données, c'est:
- De pouvoir utiliser les transactions (ce que je peux simuler avec des
semaphores on est d'accord)...
- Garantir qu'en cas de probleme on ne perd aucune donnée, et la, je suis
désolé, mais je n'ai pas encore trouvé comment backuper la base et les
fichiers en meme temps garantissant ainsi que les chemins des fichiers
correspondent bel et bien a des fichiers physique.
- Au niveau sécurité (puisqu'il s'agit d'une application WEB), il est
toujours plus simple d'aller récuperer un fichier sur un serveur plutot
qu'un information dans une base de donnée!!!
- Enfin et c'est pas l'un des moins, la gestion par fichier risque souvent
(pas toujours) de laisser trainer quelques fichiers sur le HD qui n'ont plus
de raison. pour une raison x ou y on supprimer un enregistrement, on oublie
deffacer le fichier et voila...

Bref, ma question n'est pas de savoir si on peut faire autrement, mais
plutot de savoir s'il y a une raison de ne pas enregistrer les fichiers dans
la base !

Etienne

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Etienne SOBOLE wrote:

Bref, ma question n'est pas de savoir si on peut faire autrement, mais
plutot de savoir s'il y a une raison de ne pas enregistrer les fichiers
dans la base !

Etienne

Dans notre application CMS (un dev maison), tout les fichiers sont
directement dans PG (en bytea) et ça ne pose aucun probleme. On a environs
40 utilisateurs en interne plus une centaine en externe et ca marche tres
bien.

L'application tourne avec PG 7.4.x mais on a monter une machine de test pour
valider l'utilisation prochaine de la version 8.0.x.

La machine est un bi proc avec du raid 5 logiciel.

En revanche, les backups c'est un bonheur, un pg_dump par jour (en attendant
la version 8 et ses pitr) et c'est tout, absolument tout est sauvegarder.

L'avantage, c'est de permettre d'avoir plusieurs machines frontal et une
machine pour la base de données. Les machines frontale n'ont qu'un peu de
code python pour aller chercher les pages web et les données directement
dans PG.

Dans ces conditions, deployer une nouvelle machine c'est simple comme
bonjour.

Dans notre application CMS (un dev maison), tout les fichiers sont
directement dans PG (en bytea) et ça ne pose aucun probleme. On a environs
40 utilisateurs en interne plus une centaine en externe et ca marche tres
bien.

L'application tourne avec PG 7.4.x mais on a monter une machine de test
pour
valider l'utilisation prochaine de la version 8.0.x.
La machine est un bi proc avec du raid 5 logiciel.

En revanche, les backups c'est un bonheur, un pg_dump par jour (en
attendant
la version 8 et ses pitr) et c'est tout, absolument tout est sauvegarder.

Sans aller jusqu'a dire que c'est exactement le témoignage que
j'attendais...
C'est exactement le temoignage que j'attendais :)

bon moi la seule différence c'est que je vais pas utiliser un bytea mais un
champ text tout bête.
juste une question pour que je me rende bien compte.
Quel est la taille d'un backup (non compréssé si possible) que je me rende
compte de la volumétrie de ta base.
parce que moi il devrait y avoir plusieurs milliers de documents ajoutté par
mois.

ce qui va nous emmener rapidement a quelques gigas de données...
oula. je n'avais pas fait ce calcul !!!

Etienne