Barrapunto

Aunque en principio podria tender a estar de acuerdo contigo, tras años haciendo pruebas, mis conclusiones difieren de las tuyas. Las mias son:
- Ten siempre una capa de abstraccion para el acceso a ficheros desde el código. Asi, podras ir cambiando, desde el sistema de ficheros a las bases de datos a ver cual se adapta mejor a tus necesidades.Mejor ser flexible que dogmatico, en informatica las necesidades varian.
- Ten en cuenta que la base de datos casi siempre es el cuello de botella de la aplicacion. No la sobrecarges inutilmente.
- Ext3 sufre a partir de 65000 ficheros por directorio. ojo
- Si optas por ficheros, el tema de la administracion, distribucion, replicacion entre varios servidores se complica, y hay que desarrollarla aparte del resto de la aplicacion. Muchos problemas y calentamientos de cabeza si los ficheros son dinamicos
- Tampoco el borrado en el sistema de archivos es la panacea, el borrado masivo siempre te tumbará el servidor, lo hagas donde lo hagas.
- controla siempre el iostat.


Por ahora, sirvo cientos de millones de ficheros y cambio de opinion cada dia, lo mejor es optar por meterlos en bbdd, pero siempre en un servidor aparte, con base de datos dedicada a tal fin.

Si, por todo lo que comentas. No, porque para algunas cosas puede ser mas complicado, por ejemplo , cuando la misma aplicacion web sirve para varios dominios aislados entre si. La gente de nopCommerce lo tiene claro, tienen abstraido el acceso a ficheros y puedes configurar donde guardarlos, en la BBDD o en el directory.

Un profesor nos decía "¿Puedes hacer una query a un campo binario que te devuelta todos los registros donde hay imágenes de morenas con ojos verdes? ¡¡¡NO!!! Entonces... ¿Porqué guardas la fotografía en la base de datos si no puedes saber que hay en ese campo?"

Para mi los ficheros son un dato mas.

Trabajo en un entorno que trabaja por capas.

• Varios servidores Apache, en máquinas diferentes
• Varios servidores de aplicaciones (SA), en máquinas diferentes
• Base de datos enorme con varios nodos

Si almacenase los ficheros como 'ruta+nombre' ¿donde los guardo?, ¿una copia en cada nodo de los SA?.

Prefiero almacenarlos en la base de datos.
Las bases de datos tienen campos para eso.

El inconveniente que ves tu de las copias de seguridad yo lo veo una ventaja. Necesito copias de seguridad de esos ficheros y la BBDD se encarga de ello.

Lo que hay que tener claro es donde se guardan las cosas. las bases de datos grandes permiten trabajar con varios tablespaces. Mete los ficheros en un tablespace especial, con tamaños de bloque adecuado, y con una política de copias diferente.

Lo cierto es que cada aplicación es un mundo, y no se puede dar una orden tan tajante como la que tu has dado, hay que estudiar caso por caso.

No se puede hacer todo de forma estricta, sobretodo en el mundo de los ordenadores (aunque los guionees y patrones suelen ser buenos, no lo son el 100% de los casos).

En mi empresa, por ejemplo, difícilmente podríamos introducir los ficheros en la base de datos. La nuestra ya ocupa alrededor de 300gb... imagina a dónde llegaríamos almacenando vídeos y fotografías...

Así, a botepronto, diría que suele ser aconsejable separar los ficheros de la base de datos aunque no lo afirmo de forma tajante.

Saludos

En general es mejor almacenar los ficheros en la base de datos siempre y cuando los ficheros no sean muy grandes. Ejemplo: en el tema imágenes "jpg, gif, etc" siempre es más práctico tenerlos en la base de datos. En mi caso, tras muchas pruebas la estimación que he hecho: si los ficheros son mayores de 20 MB mejor no guardar el fichero en base de datos.

Yo empecé trabajando hace 10 años con rutas en la base de datos, para acceder a aproximadamente 1 giga de archivos y ahora mismo trabajo con bases de datos de decenas de Teras con archivos almacenados dentro de la propia base de datos y me parece bastante mejor esta última solución. Las ventajas de almacenarlos dentro de la base de datos son:

-) Las bases de datos están diseñadas para escalar, les dices hacia qué unidad quieres que crezcan y lo hacen solas. Además no tienen problemas con nombres de archivos, de directorios, de número de archivos dentro del directorio, etc, etc... Eso lo gestiona la base de datos internamente y tu te olvidas. Los sistemas de archivos se suelen ralentizar bastante al ir añadiendo archivos en una misma carpeta y hay que dividir el contenido en subcarpetas y acaba siendo una locura, tanto la estructura de directorios que te queda como el código que tienes que meter en la aplicación para gestionar todo esto.

-) Te evitas que algún administrador del sistema te renombre algún directorio o te mueva algún archivo y la líe parda.

-) Copias de seguridad. Tengas los archivos dentro o fuera de la base de datos, tienes que hacer backups. Si los tienes dentro, un único sistema de backups te soluciona el problema. De la otra forma, tienes que tener dos, uno para la base de datos y otro para los archivos. Si quieres replicar la base de datos, también en un paso solucionas la replicación de los datos y los ficheros.

-) Seguridad. Como comentan por ahí arriba, tienes la seguridad de la base de datos y punto. De otra forma, tienes que replicar la seguridad para el acceso a la base de datos y al servidor o carpeta de archivos.

En resumen, solo les recomiendo almacenar los archivos fuera de la base de datos a mis mejores enemigos.

Aunque un sistema se ficheros esta pensado para eso, entiendo que las bbdd tampoco responden mal con los blob ya que en realidad lis almacenan aparte.
En mi caso desarrollo webs para una multinacional que tiene un hosting que no nos permite escribir en disco. Además hay varios servidores web y sólo comparten entre ellos la bbdd.
Asi que usar la bbdd para ficheros y una cache a nivel de aplicacion web ha resultado una buena opción.

Para ficheros, git es una base de datos excelente, y como "extra" tiene complementos magníficos: histórico, compresión diferencial, control de integridad, sincronización y duplicación transparente en local o por red, etc. Además, es mucho más ligero que una BB.DD. "normal", puesto que no necesita un SGBD residente.

Cómo haces un seek con un archivo en la base de datos?

Por favor, al diseñar un programa, no almacenar ficheros (imagenes escaneadas, PDF, documentos, etc...) en campos de la base de datos.

Por favor, al diseñar un sistema (que puede y suele contener varios programas), estudia las opciones, y sus ventajas e inconvenientes e ignora comentarios sin argumentos demostrables de barrapunto.

Una Base de datos, es una base de datos, no un sistema de ficheros.

Falso de nuevo. Una base de datos es una base de datos. Si tu mismo lo repites, te debería quedar claro. Una base de datos es una colección de datos, y el sistema de archivos podríamos hablar que es una de las bases de datos más extendidas.

Los ficheros (salvo contadas excepciones) se deben almacenar en un sistema de ficheros, que para eso están.

Falso. Depende de para que se necesiten, la velocidad de acceso que se requiera, el ancho de banda que se necesite, la disponibilidad, el número de réplicas necesario, la forma de actualizar ese archivo, se puede optar por cualquier sistema. Por ejemplo, en couchdb es muy normal guardar archivos adjuntos en los documentos, y es más, se recomienda su uso.

La base de datos sólo necesita los campos de ruta y el nombre para llegar hasta el fichero.

También podría necesitar el nodo en el que está almacenado. A veces tirar por almacenar en la base de datos solo referencias, te hace incrementar mucho el nivel de complejidad del sistema, ya que no hay integración entre el sistema de archivos y la aplicación, si se borra un archivo desde otra aplicación, hay que modificar esa aplicación, para que además de borrar ese archivo, actualice la base de datos. Y pregunto. Si no se borra de la base de datos, y si del disco, hay que hacer un rollback, si pasa al reves... ¿Qué hacemos?

A veces esa opción añade más complejidad al sistema.

Ventajas de almacenar ficheros como ficheros:

Totalmente falso.

Backups mucho más rápidos

Bases de datos como mongodb (si quieres con gridfs), ya distribuyen y duplican contenido, quitando la necesidad de hacer backups, por lo que no es que sea más rápido usar una base de datos, es que no hay que hacer nada.

Tiempo de recuperación frente a desastre mucho más corto

Recuperación. En caso de que algún nodo caiga, el contenido está replicado en otros servidores, por lo que simplemente se replica a otro nodo. Luego no hace falta restaurar. Una vez más, el no hacer nada es más rápido que el hacerlo.

Migraciones mucho más fáciles.

Migraciones. Depende de que a que se quiera migrar, hacer migraciones de ext3 a gfs, implica un tiempo de replicación que puede implicar tener apagado el site completamente.

Posibilidad de aumentar la cantidad de ficheros guardados

Depende del sistema de archivos que uses. Te invito a crear con ext3 un directorio con 60000 archivos y hacer un ls, aunque sea con > /dev/null, y ver cuanto tarda.

flexibilidad para moverlos.

Mueve un archivo entre sistema de archivos, o entre nodos. ¿Tal vez tienes que bloquear la aplicación hasta que el archivo aparezca en el otro nodo? Luego tienes que programar lógica adicional en la aplicación para trabajar con ficheres.

No tener una BBDD que crece descomunalmente.

Define descomunalmente. Seguro que hay alguna solución.

Menor ocupación en disco duro, ya que las BBDD no siempre liberan el e

¿Un blob binario es un fichero? ¿? ¿¿?? ¿¿¿???
¿QUÉ es un FICHERO?
¿¿¿???
En serio, ¿qué es un fichero?

¿Y de dónde sale toda esta ética SQL? "El deber"...

Wow.......

Échale un vistazo a NoSQL anda... Las ideas arcaicas que os meten en los cursos y los libros os bloquean la mente... Todo es posible bajo ciertas circunstancias.

El qué va funcionar mejor, si una base de datos especializada o un sistema de ficheros, va a depender fundamentalmente de la implementación de ese SGBD o de ese sistema de ficheros.

Hay base de datos que manejan muy bien contenidos grandes y la mayoría de implementaciones de SGBD están diseñadas para ser escalables y poder funcionar en arquitecturas distribuidas cambiando tan solo la configuración. Así mismo hay sistemas de ficheros distribuidos que también son muy escalables y tienen todo tipo de opciones para manejar répiclas, que van mucho más allá de lo que permite un NAS.

La ventaja de usar ficheros es que la interfaz es simple y se puede cambiar de sistema de ficheros sin cambiar la interfaz; pero muchas plataformas como Java te ofrecen acceso a SGBD con una interfaz bastante independiente de la implementación. Una desventaja de los sistemas de ficheros, es que si el sistema de ficheros es distribuido, en realidad el flujo de datos es menos directo: en lugar de conectar directamente al servidor, se hace llamada al sistema operativo, que a su vez dirige a sistema de ficheros FUSE, que a su vez contacta con el servidor remoto. Así mismo el kernel hará su política de cacheado, pero puede funcionar mejor una ad-hoc.

Hablar bien no cuesta un huevo, y quedas de puta madre. "Por favor, no almacenéis ficheros..." en vez de "Por favor, no almacenar ficheros...". Lo mismo en el título.

Gracias.

Porque para que uno venga a barrapunto a soltar una parrafada "magistral" sobre cómo hacer y no hacer cosas habrá tenido que pasar algo realmente estresante, ¿qué fue? ¿un bug de esos que te atrapan durante toda la noche? ¿una discusión con tu jefe sobre diseño de sistemas (que el jefe zanja con un "aquí mando yo y se hace como yo diga")? ¿una revisión de examen con mala salida?

Este podría ser un tema tanto o más interesante que el original...

Por ejemplo, en la administración pública tienen unos scanners especiales de alta velocidad que escanean una burrada de documentos oficiales cada minuto. Y además de hacer un OCR a la imagen escaneada guardan los ficheros TIFF (que ocupan un huevo y parte del otro).

Dudo mucho que los ficheros los guarden en una base de datos, no existe en el mundo disco duro o array de discos duros lo suficientemente grande para guardar todo eso.

Otra cosa es si estas haciendo una aplicación de gestión de personal y quieres guardar la foto del empleado, aunque sea una empresa de 5000 empleados seguro que hay espacio de sobra con un disco duro de 800 o 900 gigas

Hola, En mi caso que tengo pocos recursos ( muchas cosas que hacer, poco tiempo, base de datos "caseras", servidores "canijos", etc) Ha funcionado bien lo siguiente: A los usuarios les digo que dejen los archivos en determinadas carpetas (una para cada cosa) y que en el nombre del archivo pongan lo que quieran + un dato clave (codigo del artículo, n de factura, n de pedido, etc). Desde el programa, según se navega por los registros, se examina la carpeta correspondiente y se muestran en el menú, como ficheros relacionados aquellos cuyo nombre contengan el datos clave. Pulsando el usuario en el fichero puede, desde el program abrirlo o imprimirlo. Funciona con todos los ficheros cuya extensión está registrada en el s.o. y éste elige automáticamente el programa con el que abrirlo/imprimirlo. Yo metería los archivos en bases de datos en los casos que quieras controlar las ediciones de los mismos, controlar los accesos, etc.

Con esa filosofía incluso el vi es un SGBD.