¿Archivos adjuntos dentro o fuera?

[[newtron]]

Hola.

Aunque este tema se ha tocado de pasada en otros hilos sigo teniendo el gusanillo de no verlo totalmente claro y por eso abro este hilo.

Aunque he buscado y no he encontrado ningún hilo relativo a esto si lo hay por favor remitidme a él.

Me toca hacer una pequeña gestión documental y mi duda es si los archivos que se escanean meterlos dentro de la base de datos o solamente guardar la ruta y el nombre del archivo y guardar el archivo directamente en una carpeta del disco duro.

Hasta ahora siempre lo he hecho de esta manera, con los archivos fuera de la base de datos, pero sigo teniendo la duda si es la mejor opción.

A mi forma de ver los pros y los contras son los siguientes:

Ficheros Aparte
Pros

- La base de datos se hace bastante más ligera al guardar solo la ruta y el nombre del archivo.
- En caso de corromperse la base de datos los archivos siempre están.

Contras

- Si son muchos ficheros que se guardan en la misma carpeta puede no gustarle mucho al windows.
- Al estar aparte el tema de las copias de seguridad se complica.

Dentro de la base de datos
Pros

- Es más cómodo de manejar.
- Copias de seguridad integradas con los demás datos.

Contras

- La base de datos se puede hacer enorme y por lo tanto engorrosa de manejar a la hora de hacer actualizaciones de la misma, reestructurarla, etc.
- En caso de desastre se pierde todo, datos y documentos.

El caso es que tengo mis dudas y me gustaría comentarlo con vosotros antes de empezar con el tema.

Gracias por vuestra atención, vuestras sugerencias serán bien recibidas como siempre .

[ecfisa]

Hola newtron.

Yo también he optado por el mismo método, guardar la ruta y el nombre de archivo.

Si bién el límite de es de 4.294.967.295 archivos, la performance de acceso puede caer drásticamente cuando se superan los 10.000 archivos por carpeta. Pero eso no es mayor problema en los casos que podés agrupar los adjuntos por algún critério (cantidad de registros por ejemplo), e ir
creando diferentes carpetas para ubicar las distintas agrupaciones de adjuntos.

Me parece que la ventaja de tener una base de datos ágil, compensa con creces las dificultades que puede presentar la confección del resguardo.
Pero al igual que vos, no he encontrado opiniones sobre el tema como para asegurar que sea la mejor política a seguir...

Un saludo.

[marcoszorrilla]

Yo estoy a punto de incluir en una aplicación la fotografía de los productos, unos 2.500 y tengo decidido crear una carpeta con las fotos y una foto para las que no se encuentren aún.

Es decir, pincho en un producto y me busca la foto en la carpeta y si todavía no se ha creado me mostrará una imagen guardada a tal efecto.

Un Saludo.

[Casimiro Notevi]

Pues yo los pongo todos en la base de datos y ¡listo! , ¿qué ocupa más?, bueno, no pasa nada, pero sólo es un archivo, te despreocupas totalmente porque en el backup diario van todo junto.
Entiendo las posibles ventajas de guardarlos fuera, pero es que, hasta ahora, nunca jamás he tenido ningún problema dejándolos dentro de la base de datos. En caso de hipotética rotura de disco duro entonces sólo hay que coger el último backup, se acabó.

[[newtron]]

Amigo Casimiro, y ¿cómo de grandes se te hacen las bases de datos?, ¿no es engorroso manejar bases de datos de varios gigas?

[Casimiro Notevi]

Pues nada engorroso, la verdad.
La instalación típica en el 99% de nuestros clientes es un servidor linux y los clientes windows con el programa de gestión en delphi 5 + IBX + Firebird 1.5 y el tamaño de las bases de datos oscilan entre... un momento, ahora vuelvo, voy a hacer unos cálculos... vale, ya estoy de vuelta, las más pequeñas alrededor de 0,5 GB y la mayor está casi en 30 GB, la mayoría están todas por encima de 1 GB, (1, 3, 5, 8, 12, 16, 21) son la mayoría, aunque de muchos clientes no tengo ni idea porque los atiende mi compañero.
Normalmente se hace un backup cada noche y mientras están trabajando durante el día también se está creando una "shadow" al mismo tiempo en otro disco de red. Ningún cliente tiene problema por lentitud ni nada de eso, trabajan "normal" y la mayoría ni siquiera sabe lo que ocupa la BD.
En caso de avería de un disco (algo que ocurre) el restaurar una BD de algunos gigas tarda un rato, evidentemente, pero nada preocupante. Además que el backup que se hace cada noche, primero hace una copia de la BD y luego sobre esa copia es con la que hace un gbak. Así que normalmente lo único que hay que hacer es copiar en el nuevo disco la copia que se hizo durante la noche, ni siquiera hay que restaurar el gbak, por lo que en un rato tienes el servidor andando de nuevo.
Y todo esto es cuando se rompe un disco, o sea, una vez cada varios años.
Además jugamos con otra ventaja, a la mayoría de nuestros clientes les tenemos montado un sistema RAID 5, así que se les estropea un disco y ni se enteran hasta que un día vamos por allí y vemos una led rojo parpadeando, se le pone un disco nuevo en lugar del averiado y, ya digo, ni se enteran.

[[newtron]]

Empezado por Casimiro Notevi

...a la mayoría de nuestros clientes les tenemos montado un sistema RAID 5

cuñu.... manejas clientes potentes entonces, lo que es trabajar en una capital.... ains....

[Casimiro Notevi]

Bueno, son más o menos "normales", lo que ocurre es que cuando se les presenta un presupuesto siempre llevan una serie de exigencias por seguridad, una de ellas es montar un RAID y otra es tener internet para que podamos acceder desde cualquier sitio, en caso de que no acepten esas condiciones (y otras) entonces "no nos hacemos responsables de sus datos y tal, y tal y tal..." , aunque últimamente con la crisis es que casi ni siquiera salen clientes nuevos, pero eso es otra historia.
Ten en cuenta que lo del RAID es algo relativamente económico hoy en día, y la seguridad y tranquilidad que aporta es muy grande.

[Neftali [Germán.Estévez]]

Hay que tener en cuenta que la solución puede variar dependiendo del número de los ficheros y del volumen de estos.

A parte de esto, algunas puntualizaciones...

Empezado por newtron

Contras

- Si son muchos ficheros que se guardan en la misma carpeta puede no gustarle mucho al windows.
- Al estar aparte el tema de las copias de seguridad se complica.

- Nunca se almacenan muchos ficheros en un mismo directorio, eso ralentiza mucho el acceso. Por decir algo, en un directorio, nunca debe haber más de 5000 ficheros o subdirectorios en su interior. Con esta premisa se trata de generar un arbol de forma que el ancho de cada nivel no sea superior a ese número.

- Lo de que las copias se complican, depende; Como ya he dicho antes todo esta en el numero de ficheros y su volumen. Si la base de datos crece demasiado (GB) es más complejo generar copias de ficheros tan voluminosos y más sencillo de la estrucura de directorios. Si la Base de Datos es "relatívamente pequeña" (con los ficheros dentro), siempre es más sencillo hacer la copia de un único fichero.

Un saludo.

[[rretamar]]

Acá van mis dos centavos al tema:

Mi recomendación es que si los archivos son muchos los almacenes fuera de la base de datos. En mi caso, tengo una columna que guarda el nombre de los archivos y de esa manera la base de datos queda muchísimo más pequeña (varios megas contra varios gigas...ups...una diferencia muy apreciable). En cuanto al almacenamiento de los archivos externos, los almaceno cronológicamente, creando automáticamente directorios por años, meses y días....de esa forma evito tener muchos archivos en el mismo directorio (y todo queda mucho más ordenado, facilitando incluso el acceso "manual").

Es más, para asegurar cierta redundancia, dentro del nombre de los archivos guardo algunos datos importantes de los mismos, suficientes para en el caso de que ser "rompa" la base de datos (algo que nunca ha sucedido y se lo debo a Firebird) poder reconstruirla leyendo recursivamente toda esa estructura de directorios. Esto que cuento lo tengo funcionando 24x7 desde hace años y cero problemas.

Para respaldar esa estructura de archivos utilizo el software RSYNC (es software libre, viene incluído en todas las distribuciones de Linux), que me permite respaldos incrementales con muchísimas opciones de personalización.

[[newtron]]

Amigo Casimiro. Esta vez el criterio de "la familia" difiere del tuyo. Yo particularmente aunque no lo sigo teniendo claro 100% seguiré dejando los archivos fuera de la base de datos .

Gracias a todos y un saludo

[Casimiro Notevi]

Es que todo el mundo está equivocado, menos yo

[Julián]

Ficheros Aparte
Pros

Empezado por newtron

- La base de datos se hace bastante más ligera al guardar solo la ruta y el nombre del archivo.

CIERTO. Oracle, que algo debe saber del tema usa la misma técnica, pues su tipo de campo BFILE es en realidad el nombre del archivo que esta guardado en un directorio, el cual podemos asignar con la instrucción sql SET DIRECTORY, o algo así, pues hace mucho tiempo que no lo uso. Y ellos mismo recomiendan usar dicho tipo de campos en detrimento de los BLOB.

Empezado por newtron

- En caso de corromperse la base de datos los archivos siempre están.

CIERTO. Y ademas, tenemos cosas como rsync y raid para garantizar al 100% la seguridad de los datos.

Contras

Empezado por newtron

- Si son muchos ficheros que se guardan en la misma carpeta puede no gustarle mucho al windows.

FALSO. Si es necesario podemos dividir en varios directorios, clasificando por fechas, nombres, etc. Y hay otros sistemas de archivos que no son tan quejicas como los típicos de Windows.

Empezado por newtron

- Al estar aparte el tema de las copias de seguridad se complica.

FALSO. Como muy bien dicen rretamar, casimiro o meftali hay cosas como rsync, raid, cron, TM en mac, que permiten automatizar los backups y "despreocuparse", y así tendremos una bd muchisimo mas ligera, y más facil de respaldar, cosa para la que tambien podemos usar las herramientas citadas, claro.

Dentro de la base de datos
Pros

Empezado por newtron

- Es más cómodo de manejar.

FALSO. Juntar un path y un filename y hacer lo que sea con un archivo es mucho mas fácil, y lógicamente, portable, que extraer un campo BLOB de una tabla, proceso que puede ser bastante distinto de uno a otro tipo de bases de datos.

Empezado por newtron

- Copias de seguridad integradas con los demás datos.

CIERTO, pero tambien nos pueden servir los argumentos anteriores (archivos fuera y bd mas ligera) para convertir este pro en una contra.

Contras

Empezado por newtron

- La base de datos se puede hacer enorme y por lo tanto engorrosa de manejar a la hora de hacer actualizaciones de la misma, reestructurarla, etc.

CIERTO. Y obvio.

Empezado por newtron

- En caso de desastre se pierde todo, datos y documentos.

CIERTO. Y obvio.
Y es muy normal que la periodicidad de las copias de los archivos pueda ser distinta, mas espaciada, que la de la BD, pues en la mayoría de las situaciones los archivos adjuntos, fotos, etc, se tocan menos que los demas datos.

Estoy imaginando como sería de gorda la bd de mi curro si llevara los ficheros dentro, ¿que hay por encima de los terabytes? XDD

No obstante hay un punto a favor de los "ficheros dentro" que creo no habeis mencionado, y es que, en un momento dado, tenerlos dentro nos podría permitir un cierto nivel de privacidad, por ejemplo, podemos imaginar una base de datos que tenga fotos de tias en pelotas y no podriamos verlas si no las hemos obtenidos con un SELECT. Aunque, claro, si estuvieran fuera tambien podriamos tener los ficheros encriptados o simplemte en una ubicación "protegida", o usar algo similar al BFILE de Oracle si la BD que estemos usando lo tiene. O sea, que este último punto es una chorrada, pero era por poner lo de las tias en pelotas. XD

[Casimiro Notevi]

Hay otra alternativa que combina lo mejor de los dos mundos (qué bien me ha quedado ).
En ciertos proyectos he usado 2 bases de datos, una para los datos y otra para las imágenes. A ver... pros y contras

[[RONPABLO]]

Yo uso una base de datos para los datos y otra para guardar imágenes, el archivo obvia mente crece mucho, pero no mucho más de lo que crecería la carpeta que contenga a todas las imágenes y listo, para mi fue un gran descanso ya que mis clientes no tienen departamento de sistemas y en su gran mayoría desconocen de configuraciones del sistema... a que va esto, pues resulta que en muchas ocaciones en windows XP al poner la ruta donde guardaba las fotos en el "servidor" (por ejemplo \\equipo\fotos) no me corría bien, me tocaba indicarles por teléfono o pro asistencia remota como ir y comprobar si era que por algún motivo habían perdido la configuración de compartir, o en muchas ocasiones simplemente solo me funcionaba bien dando la dirección IP (\\192.168.0.1\fotos por ejemplo) y se juntaba con DHCP... en fin luego de mucho dudar me cambié y no me arrepiento.

el manejar la ruta del archivo lo haría de nuevo solo si fuera capaz de hacer una UDF que me he imaginado llamada pathToBlob, pero desafortunadamente no fui capaz de hacerla. con las copias de seguridad, pues para mi gusto (que se que hay muchos) prefiero entenderme con menos archivos.


respecto a:

Pros

- La base de datos se hace bastante más ligera al guardar solo la ruta y el nombre del archivo.

El tamaño de los archivos va a ser el mismo o casi el mismo, simplemente en la bd tiene un solo archivo en las carpetas tienes tal vez miles (mis clientes siendo pequeños llegaban a fácilmente a tener a más de 10 mil imágenes) pero si te decides a esta forma te recomiendo que nunca hagas un "control c", "control v" en el explorador de windows, es más que eterno, tal vez con las herramientas que te comentan sea una mejor experiencia pero el explorador validad todos los archivos antes de iniciar la copia y es muy lento, hablo de haberme ido a almorzar y regresar a las dos horas y aun seguir esperando el pasar una carpeta con 2G de fotos, cosa que con un solo archivo (que he llegado a las 6G en mis clientes actuales) no me he demorado más de 15 min (y esto fue en un win XP que pedía a gritos formateada)

- En caso de corromperse la base de datos los archivos siempre están.

en caso de corromperse y no tener BKUP de las rutas da casi lo mismo tener dies mil archivos sin saber a quien pertenece que tener un archivo de 2G sin acceso.

Contras

- En caso de desastre se pierde todo, datos y documentos.

¿en caso de desastre es que?? ¿que el disco duro se dañe y no se pueda recuperar? ¿eso no le pasaría si tuviera imágenes o archivos distribuidos por carpetas? la mejor forma de hacer copias de seguridad es tenerlas fuera del equipo y mejor aun si están por fuera de la oficina o edificio donde esta el servidor.

[marcoszorrilla]

Lo que dice Casimiro de utilizar 2 bases de datos lo he hecho algunas veces y me parece buena idea, siempre y cuando el motor te permita abrir las dos bases de datos a la vez y hacer un Select involucrando tablas de una y otra.

Un Saludo.

[[newtron]]

Pues la verdad es que el tema de una base de datos independiente para las imágenes no me resulta desagradable, en caso de ser una aplicación multiempresa sería (imagino) una base de datos de imágenes por cada empresa. Pensaré en ello seriamente.

P.D.: bueno.... pensar pensar .... eso de pensar no sé si me saldrá

[pacopenin]

Hola.

Parece que ya se han respondido la mayoría de dudas a este respecto, pero me gustaría ahondar sobre el tema de la privacidad que comenta julian. Si los archivos están "fuera" son accesibles por lo usuarios sin pasar por el filtro de la base datos. Pueden ser vistos, modificados y eliminados desde fuera de la aplicación. Si esto es un factor importante también debe ser tenido en cuenta. Mi experiencia me inclina hacia la solución de guardarlo en la base de datos y si el número de archivos se estima realmente alto, guardarlo en varias BBDD como comenta Casimiro, incluso por años, o por tipos de archivo (imagenes, pdf, doc) etc.

Saludos,

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Hay otra alternativa que combina lo mejor de los dos mundos (qué bien me ha quedado ).

Y lo peor también...

Empezado por Casimiro Notevi

En ciertos proyectos he usado 2 bases de datos, una para los datos y otra para las imágenes. A ver... pros y contras

Partiendo de la Base de que no hay solución genérica para todos los casos. Porque la solución tiene mucho que ver con determinados aspectos que cambian en cada caso concreto.
* Tamaño total y/o número de ficheros. Cambia todos los planteamientos tener una Base de Datos de 5 GB o tener una de varios TB.
* Uso que se hace de ellos y las operaciones que necesites.
* Requerimientos de seguridad (lo han comentado Julián y pacopenin).

Volviendo a lo comentado por Casimiro se me ocurre:

PROS:
* Las operaciones con las imágenes no perjudican el resto de accesos a la Base de Datos. Bueno si hay muchas operaciones que no implican a las imágenes, porque eso mantiene la BD "sin imágenes" más pequeña, más manejable, más ágil...
* Mejora sustancial de las copias de seguridad (respecto a 1 Base de Datos). Seguramente la copia de la BD-Datos será más habitual, mientras que la BD-Imagenes se puede hacer con una cadencia más pequeña. El movimiento de datos en la 1ª seguramente será mucho más alto que en la segunda, de forma que podemos adecuar la periodicidad de las copias a esa relación.


CONTRA:
* Las consultas se me antojan más complejas incluso se deberán realizar más consulta para obtener lo mismo que si estubiera todo junto.
* (sólo para casos de gran volumen) Los SGBD's no están pensados para obtener máxima eficiencia en este escenario (2 Bases de datos o 2 servidores); Es más, se me antoja que las consultas con esta estructura serán poco eficientes.
* Un borrado o una actualización implica doble de operaciones.
* Dudas sobre la "integridad de los datos" si están en BD diferentes. Claves foráneas?¿?¿?

Empezado por pacopenin

Si los archivos están "fuera" son accesibles por lo usuarios sin pasar por el filtro de la base datos. Pueden ser vistos, modificados y eliminados desde fuera de la aplicación. Si esto es un factor importante también debe ser tenido en cuenta. Mi experiencia me inclina hacia la solución de guardarlo en la base de datos y si el número de archivos se estima realmente alto, guardarlo en varias BBDD como comenta Casimiro, incluso por años, o por tipos de archivo (imagenes, pdf, doc) etc.

Es algo que hay que tener en cuenta, pero no quiere decir que deba ser así. En ese caso se trata de que los ficheros no sean accesibles para todo el mundo. Una opción, por ejemplo es crear un "servidor de ficheros".
Básicamente es un programita al que le pides (utilizando tu autentificación) el fichero que necesitas, de forma que el único que tiene acceso a los ficheros es el servidor y lo que hace es recibir peticiones y "servir" ficheros.

Esto implica una sobrecarga de programación y volvemos a lo de siempre. Depende de cómo sea el proyecto tendrá sentido asumirla o no.

[Casimiro Notevi]

Bien, veo que mi propuesta va ganando adeptos
También hay que tener en cuenta que en mi caso sólo usamos servidores linux y si estuviesen en directorios distintos tendría que estar compartiéndolos por samba y sería una puerta abierta a que cualquiera pueda entrar y borrarlos o moverlos de sitio y luego... a ver quién los encuentra.
Además es una opción que funciona muy bien tanto en linux como en windows (para quien quiera seguir usando un "servidor" windows) ya que sólo es un archivo más, fácil de controlar, copiar, etc.
En fin, que eso de tener miles de ficheritos repartidos por distintos directorios y que sean accesibles por cualquiera desde fuera... no me hace ninguna ilusión.