|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Utiliza base de datos
(Puntos:5, Interesante)( http://www.baidez.net/ )
- Si la cantidad de ficheros a almacenar es muy grande y la capacidad no importa yo los pondría como campo en la BD. En el momento que están insertados tienes las mismas ventajas que el resto de información que almacenes en la DB, vease tratamiento de consultas, seguridad de acceso según usuarios, coherencia, etc. Por no comentar que lo tienes centralizado sin importante donde reside la información o si se te corrompe el sistema de ficheros (el SGDB te hace hasta el backup).
- En caso de que el número sea pequeño y el acceso lo quieras más primitivo aprovecha el sistema de ficheros.
Yo, personalmente, en cosas muy serias y con grandes cantidades de ficheros lo pondría con DB, sino no.
If you don't know where you are going, you will probably end up somewhere else.
Laurence J. Peter
Re:Utiliza base de datos
(Puntos:5, Interesante)( http://barrapunto.com/ )
mejor en el sistema de ficheros
(Puntos:4, Informativo)( Última bitácora: Domingo, 04 Septiembre de 2005, 12:57h )
No creo que sea una buena idea sobrecargar la base de datos haciendo que se ocupe tambien de los ficheros, ya que esto supone un importante volumen de datos que manejar.
PISO Pontevedra con Garaje. Rias Baixas. Sanxenxo. Centrico. Playa. [pisopontevedra.com.es]
Los ficheros, en sistemas de ficheros
(Puntos:3, Interesante)Si los ficheros pueden ser cualquier cosa, y la base de datos no va a tratar con el contenido del fichero propiamente dicho, creo absurdo usar blobs, entre otras cosas, porque ocuparán más espacio en el disco duro sin añadir información. Además el acceso será mucho más lento.
De todas formas, como en todo, depende. Depende del tratamiento, de la aplicación en si, de la tecnología empleada, etc.
Por ejemplo, si no recuerdo mal, el Oracle Forms (es decir, lo que haces con el Oracle Developer) guarda los ficheros en blobs, pero es por la filosofía de Oracle "todo es la base de datos".
Una ventaja de usar ficheros normales y corrientes es que puedes poner accesos alternativos sin necesidad de usar la aplicación cliente de la base de datos. Puedes hacer que se pueda llegar a los ficheros desde directamente ftp, NFS, SMB, webdav, etc. sin la intervención de la base de datos.
Re:Los ficheros, en sistemas de ficheros
(Puntos:4, Informativo)( http://barrapunto.com/ )
1 - Si utilizas una herramienta de Backup para Oracle es dificil incluir la ruta donde dejes los ficheros.
2 - En caso de corrupción de la partición no tienes las herramientas de recuperación que puede tener un gestor de Base de Datos como Oracle.
Si guardas la información en la BD como un campo LOB puedes separarlos en otro tablespace diferente para evitar problemas en el tablespace de datos. Los ficheros también se pueden enviar directamente sin necesidad de realizar un ftp o exportar directorios por NFS o SMB. En el cliente puedes recuperar el fichero mediante una SELECT a dicho campo utilizando las estructuras correspondientes el PL/SQL o mediante ProC o su equivalente en Java.
Creo que Oracle también se encarga de realizar la compresión de dichos campo LOB.
¿Como lo hace los sistemas documentales existentes, tal como Documentum? Guardan los ficheros en campos LOB de la BD Oracle o similar.
Mi opinión
(Puntos:2, Informativo)Sin duda no lo almacenes en la base de datos ...
(Puntos:3, Informativo)( http://www.loeda.es/ | Última bitácora: Sábado, 04 Agosto de 2012, 14:10h )
En su tiempo diseñe una base de datos que almacena fotos de placas, corria sobre MSSQL Server y las placas se almacenan en el base de datos, con el tiempo (apenas 90 dias) la base tenia ya 2G de tamaño y las copias eran una locura, ademas menear este tipo de campos (los que contienen la imagen) son siempre muy problematicos.
Recomendación, almacenalos en ficheros, y en la base de datos una refencia al fichero, es mucho mas facil
La Zapatilla Azul [loeda.es]
Et in terra pax hominibus bonæ volu
Sin duda Depende....
(Puntos:4, Interesante)Depende del SGBD y del Servidor
(Puntos:2, Informativo)Depende de muchas cosas...
(Puntos:2)Por ejemplo, si se tratase de Oracle (a partir de la versión 9i), si los ficheros fuesen documentos XML, si hubiese muchos y de cualquier tamaño y si pretendieses luego acceder a la información que contienen de manera eficiente y directamente a partir de consultas SQL de la misma forma que si se tratase de datos en tablas (es decir, internamente indexados), entonces en ese caso sin duda alguna, utiliza las funcionalidades que para ello te ofrece Oracle y su potentísimo soporte para XML. Todo serán ventajas.
Sin embargo, esto es sólo un ejemplo muy específico. Para cualquier otra necesidad, hay que estudiar a fondo los pros y los contras de tomar una u otra decisión y, sobre todo, tener muy claro lo que se pretende y cuánto se está dispuesto a pagar (en términos económicos y no económicos, como rapidez de acceso, optimización del espacio...).
En fin, me parece que a no ser que tu caso sea como el que expongo, no te habré ayudado demasiado, pero mira que si lo fuese... ;-)
Un saludo, ¡y suerte!
Yo soy de los de base de datos
(Puntos:3, Interesante)El volumen es mas o menos importante, unas 20000 mensuales y bueno, me parece una chapuza informática meter semejante número de ficheros en un sistema de archivos (y no es güindon, no señor).
Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.
La base de datos usada es PostgreSQL, y sobre el asunto que comentan por ahí del tamaño de las copias, para copiar solo los datos, pg_dump, sin opcion -b, si quieres los blob, con -b, de todas maneras si hay que hacer un backup de las imágenes, también ocuparán lo suyo aunque sean archivos.
Pero como siempre, para gustos, los colores
Re:va a ser gigante esa base!!!
(Puntos:4, Inspirado)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Me pongo un vestidito rosa y unas gafas redondas cual azafata del "un dos tres" para decir, calculadora en mano, que:
"700kb cada imagen por 20.000 imágenes al mes suponen una base de datos con un crecimiento de... ¡14 Terabytes mensuales! que multiplicados por 12 meses que tiene un año suponen... ¡1´7 Petabytes anuales! ¡Sólo en imágenes! ¡Sin contar las tablas auxiliares y los índices sobre las mismas!"
Me rasgo el vestidito rosa y me quedo en bolas para decirte que como metas eso en posgreSQL la hostia que te vas a dar va a ser escuchada desde la estrella Vega. Si me cuentas que el posgre lo usas para los campos índice y que las imágenes van a un IXOS [ixos.com] me lo creo. Pero si me cuentas que vas a meter una BBDD de ese tamaño en posgre, sólo me queda preguntarte por la fecha del pase a producción para ir encargando la corona de flores.
En España la mejor manera de guardar un secreto es escribir un libro.
se almacena la URI.
(Puntos:2)( Última bitácora: Lunes, 07 Febrero de 2005, 03:05h )
En la base de datos se debe guardar la URI del archivo en cuestión, de la forma mas independiente de la plataforma que sea posible.
Prefiero el sistema de archivos
(Puntos:2, Interesante)Personalmente me inclino por guardar los archivos en el disco duro teniendo las debidas relaciones en la BD....lo digo porque hace poco termine una aplicacion que se encarga de almacenar un historial de imagenes gigantesco, y era necesario efectuar copias de seguridad constantemente...y hacerlas basados en la BD resultaba muy tedioso para cliente, asi que las imagenes se iban organizando en carpetas segun la capacidad del disco en donde se fueran a quemar de manera automatica.
De esta forma resulta mucho mas facil realizar las copias, sin embargo era necesario que los archivos se cifraran y que solo a traves de la aplicacion se pudiera tener acceso a los mismos.
Robots de almacenamiento masivo
(Puntos:3, Redundante)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Bueno, ya te han dado algunas respuestas y no tiene mucho sentido que vuelva a escribir lo mismo que han escrito los demás. Sin embargo, nadie ha comentado nada de almacenamiento masivo, así que aun hay espacio para una pequeña aportación:
No creo que se trate de un sistema grande porque si lo fuese no se lo darían a alguien que pregunta a Barrapunto (lo siento, no he podido resistirme) y no creo que se trate de un sistema pequeño porque ni siquiera te plantearías meter los archivos en la BBDD.
En resumen, que mi respuesta es que metas los archivos en la BBDD, que así queda el sistema más """aerodinámico""" :P
En España la mejor manera de guardar un secreto es escribir un libro.
Meter o no meter ;)
(Puntos:2)( http://www.jmcresearch.com/ )
Si lo que quieres es explotar el contenido de los archivos (hacer búsquedas dentro de ellos y pirulas variadas) puedes preguntarte a ti mismo si te merece precachear esa información en la propia base de datos (por ejemplo, con una estrategia de acceso que te permita generar un "resumen" y almacenarlo en la base de datos).
Si lo que te pasa es que quieres ser comodón y ahorrarte un poco de programación, acuérdate que si el cliente y el servidor de base de datos se conectan por una linea de baja velocidad, acabarás precacheando en el cliente esos mismos ficheros para que la cosa vaya bien (imagina un select id,image limit 10 con sizeof(images) ~1M, sin cursores)
<your quote here> --Bjarne Stroustrup
Cuestión de requisitos, maquinaria y gustos :)
(Puntos:1)( Última bitácora: Martes, 31 Octubre de 2006, 18:26h )
Bueno, al final he decidido almacenar las imágenes porque son pequeñas (ocupan menos de 50 KBs cada una), porque de vez en cuando se borrarán ya que son para hacer debug y aunque para cada imágen debo almacenarla hasta saber si se ha introducido bien lo que ponía en ella (si lo hace mal, debo pasarla a otra tabla), es decir, estoy generando muchas imágenes pequeñas; creo que es la mejor solución para no depender de directorios ni rutas ni similares que luego al pasarlo a otro sitio tengo que andar preocupándome de guardar.
Otra cosa es si tu sistema está todo el día usando dichas imágenes, la carga sobre la BD será alta si se almacenan en ésta.
Así que yo creo que todo depende de los requisitos de la aplicación, de la maquinaria disponible (sería un suicidio poner un MySQL a manejar exclusivamente imágenes en una máquina poco potente) y también es cosa de gustos personales.
Puedes también hacer uso de una opción mixta, más bien hacer uso de cache, y dejar en un directorio las imágenes que se usan con más frecuencia; es decir, las imágenes estarían en la BD, pero las más usadas estarían en disco.
Y si te decantas por dejarlo en un directorio, pues no tienes muchos problemas; hay muchas formas de guardar la referencia a la imágen en la BD (aunque yo me decantaría por la nueva forma que tiene Mambo 4.5.3 de obtener los ficheros de disco :P )
Venga un saludo
Mi pobre experiencia
(Puntos:2, Interesante)Base de Datos: Firebird sobre linux
El sistema mediante un scripts en php coge el fax recibido por hylafax, le extrae los metadatos, le asigna un código y lo guarda (en formato tiff) en el servidor en un campo blob.
La base de datos tiene ahora 442 Mb, el primer fax lo recibio el día 2002-09-25 10:15:31.0000, y tiene almacenados 7611 faxes.
Todo va perfecto, se facilita la catalogación y redistribución de los faxes pero lo cierto es que en una pyme no se pueden pedir grandes inversiones en infraestructura informática. Con este tamaño tarda mucho a la hora de hacer las copias de seguridad, y hay que tenerlo en una base de datos independiente de la del ERP, y se pierde la integridad referencial con respecto a las tablas de remitentes (proveedores, clientes) y de trabajadores para redistribución.
Luego para hacer la copia de seguridad hay que copiar un archivo de 409 Megas (el backup, no la base de datos original) que cambia todos los días.
Cuando pasen otros dos años seguramente esté en un nivel intolerable y haya que tomar alguna decisión.
Ahora cuando tengo un entorno intranet controlado pongo los enlaces al servidor de archivos, siempre relativos, nunca almaceno caminos completos.
Por ejemplo los archivos de pedidos, almaceno la ruta general ("\\master\ventas\pedidos") en una tabla de rutas y luego monto el path completo añadiendo la referencia del pedido. Esto me facilita la movilidad de los archivos aunque si cambias el número de pedido tienes un problema, que tampoco es tal con menos de 10 líneas de código, pero que por perro no he contemplado. Ten en cuenta que este sistema no permite el acceso remoto y solo es aplicable a la intranet, aunque esto sería facilmente salvable, al menos en linux, usando fish:// y un servidor ssh en la máquina servidora.
Pero en el caso de los faxes creo que no usaría este modelo ya que solo me permite un control de acceso rudimentario (a través de samba). Ahora montaría un servidor TCP con un protocolo de no más de 10 comandos (lo he mirado en java por la multiplataforma, manejo de hilos, etc) que autentificase contra los usuarios de firebird, determinase sus privilegios de faxmaster, e incluso restringiera a los usuarios no faxmaster en función de la distribución que hagan los faxmaster de los distintos faxes. En el cliente sería cuestión de montar la contrapartida cliente tcp y de sincronizar las gestión de los faxes en las dos direcciones: base de datos con los metadatos, clasificación y distribución y el servidor tcp de manejo de los ficheros. Incluso un sencillo scripts en php o python (por no sobrecargar con la VM de java) podría realizar una sencilla sincronización entre base de datos y archivos para eliminar basura periódicamente, y más en mi caso que pretendo gestionar también los faxes enviados con almacenamiento automático de reportes de envío, todo gracias a las bondades de hylafax, samba, php, linux,
La verdad es que montarlo sobre otro sistema propietario sería horrible, por lo pronto mediante samba guardo los fax a enviar con un simple scripts que se lanza cuando imprimes en una pseudo-impresora, y no alcanzo a saber como hacer lo mismo con el servidor CIFS de microsoft.
Bueno, espero que la batallita te haya dado al menos ideas, mi síntesis es que "guardarlo en la base de datos si vas a guardar muchos archivos es la forma fácil pero no creo que sea la mejor".
Yo al contrario de otra persona que te respondio antes, solo lo uso para ocasiones en que no se vayan a almacenar muchos archivos y por ello no merezca la pena complicar el diseño de la estructura servidora y la programación del cliente.
Esto te permitirá también una mayor independencia con respecto a tu SGBD, si la incluyes en el servidor y crece mucho (como parece tu caso que además tiene unas necesidades muy concretas), con el tiempo tendrás que tirar de sistemas SGBD como Oracle y todo por no haber curra
Los ficheros en el sistema de ficheros
(Puntos:2)Esta pregunta nos la hemos planteado muchos. En mi experiencia es mejor guardar los ficheros en el sitio que le corresponde, siempre que no tengas que tratar los contenidos como dicen más arriba.
Meterlos en un BLOB sólo sobrecarga la BBDD, entorpece las consultas y el acceso a los mismos es muy lento.
Una vez cometí el error de insertar en una tabla las fotos de los usuarios. Era un MySQL 3.23. Cuando la tabla llegó a 70Mb el acceso a la base de datos era lentiiiiiiiiiiisimo, y toda la aplicación se vió afectada. Consecuencia: Me tocó migrar esa tabla a ficheros normales y modificar la aplicación (pérdida de tiempo considerable).
Espero haberte ayudado. Saludos.
Como te diría Linux...
(Puntos:3, Interesante)( http://barrapunto.com/ )
¿Y no puede hacerse de las dos maneras?
Me explico.
Ya que sabes que es un punto conflictivo hazlo de manera que sea facil cambiar de un modelo a otro.
Por ejemplo: Usa una tabla en la que tengas la ruta al fichero y el campo binario del fichero y deja a null lo que no uses. Así cualquier referencia al fichero tendrá que pasar por esa tabla.
El día que descubras que la base de datos (o el sistema de ficheros) no te sirve, pues haces un proceso que los cambie de sitio y punto.
Depende, pero normalmente en BD
(Puntos:1)Que te interese guardarlos en BD o sistema de ficheros depende de muchas cosas... pero casi siempre es mejor hacerlo en BD.
Asumo que "guardar en filesystem" significa tener una tabla de la BD con un path que apunta al fichero, estando este guardado en disco, ya que guardar ficheros "a lo bruto" rara vez sirve para nada.
Ventajas de guardarlos en BD:
- La BD te gestiona la seguridad de forma coherente con el resto de la información, en el filesystem tendrías tu que preocuparte de mantener coherentes las ACL con la seguridad que hayan introducido en BD.
- El acceso es transaccional: si a mita de escritura se va todo al garete, rollback y aquí no ha pasado nada. En filesystem... no he visto nunca a NADIE implementar el acceso como dios manda, en caso de error el fichero queda corrupto y no hay forma de volver atrás. Pero es que hacerlo bien es un suplicio.
- Los backups son más sencillos.
- Puedes usar sistemas de replicación para tener tolerancia a fallos manteniendo la coherencia entre la BD y los ficheros. Si los ficheros van por libre, normalmente ni tolerancia a fallos ni nada.
- Te despreocupas de gestionar los path (¿qué pasa si necesitas más espacio y quieres guardar más ficheros en otro disco?)
Desventajas de guardarlos en BD:
- Si los ficheros son para que los use una aplicación externa (por ejemplo, documentos de word), tendrás que copiarlos a un fichero temporal local antes de abrirlos, y eso consume tiempo (ej: ficheros de video).
- A veces los ficheros no tienen significado aislados, sino que forman una estructura (por ejemplo, los ficheros .IFO y .VOB de un DVD). Hay que guardar esa estructura en la BD, y ahí empiezan los líos.
Resumiendo: como primer intento, guardalos en BD. Si tienes problemas, entonces te comes el tarro para guardarlos en filesystem, pero para hacerlo bien... agarrate que vienen curvas.
mis experiencias
(Puntos:1)Gracias por todos las sugerencias recibidas. Me queda claro.. me queda claro que existen dos grandes equipos enfrentados con este tema.
En mi experiecia: he participado en 2 grandes proyectos de software que necesitaban almacenar ficheros en el disco duro. En los 2 casos lo hemos resuelto almacenando los ficheros en el sistema de ficheros.
Esto nos ha causado algunos problemas, que ya han sido comentado arriba:
Nunca he tenido experiencia almacenando los ficheros en la BD, pero, gracias a vuestros comentarios puedo hacerme una idea de a lo que me voy a enfrentar.
Gracias.
Mi opinión.
(Puntos:2)( http://www.cientifico.net/ | Última bitácora: Martes, 22 Junio de 2004, 13:46h )
Bueno muchacho. Hata donde yo sé, depende mucho de varios factores:
Creo que lo que mejor puedes hacer (Me imagino que accedes a traves de tomcat, o un servidor web), es implementarlo de las dos maneras (unas 20 lineas de diferencia (por lo menos para las pruebas (prueba solo lo que más se valla a repetir, como la consulta, ya que la adición suele ser menor)). Tienes por ejemplo tu archivo index1 e index2. Te buscas en internet un puteador de webs (no se como se llama ahora mismo). Es un programilla que pide a tu server desde localhost, unas 1000 consultas ( o las que le especifiques), y te dice tiempo de respuesta de la página, paginas erroneas (errores 550), etc... Si te lo montas bien tambien puedes monitorizar la cpu y la ram.
Esto en cuanto rendimiento.
Espacio, no creo que ocupará el mismo o similar.
Comodidad. Almacenando en BLOB, solo tienes que hacer copia de seguridad de la base de datos. De la otra manera no.
Seguridad. Si lo almacenas en la base de datos a mi entender es mas seguro (entendiendo como seguro que hay menos probabilidades de meter la pata). Si lo almacenas en el disco duro, tienes que cuidarte de permisos y demas rollos.
Bueno guapeton, nos vemos.
Besos.
Re:No se la respuesta pero ...
(Puntos:1)Re:YO SOY DE SISTEMA DE FICHEROS
(Puntos:1)( http://www.festuc.info/ | Última bitácora: Jueves, 14 Febrero de 2008, 17:56h )
los backups del disco como los de sgbd pueden ser incrementales. igual
un rsync de 140g me tarda 20 minutos entre dos maquinas a 100mb (por que muchos de esos arxivos no varian en meses, claro :P)
mai güeb paix [festuc.info]
Re:Mételo en la BD
(Puntos:2)( http://www.jmcresearch.com/ )
El problema de base es "mucho lirili y poco lerele". El papel lo aguanta todo, y es fácil teorizar.
Lo de soluciones elegantes y tal ... pues bueno, depende de lo que entienda el por elegante, claro. Para mi, lo elegante es lo que está resuelto técnicamente impecable, hace un uso eficiente de los recursos y tiene un código mantenible y legible.
A lo mejor para el lo elegante es "Aceptar", "Aceptar", "Aceptar". Que ponga los ficheros donde le de la gana. Ya veremos que dice el cliente cuando lo use ;) (o tenga que pagar las actualizaciones de hardware)
<your quote here> --Bjarne Stroustrup
Re:un ejemplo
(Puntos:2)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Hum... ¿Cómo lo sabes?
En España la mejor manera de guardar un secreto es escribir un libro.
Re:Alguien puede dar datos/ejemplos mas concretos?
(Puntos:1)( http://barrapunto.com/ )
Lo que esa aplicación almacena en la bd no es el archivo, sino su representación en memoria. Cuando muestras un jpg, el software que uses debe procesarlo para obtener un mapa de bits. Y es ese mapa de bits lo que almacena en la bd.
A modo de ejemplo, un .jpg de unas 200 Kb ocuparía más de 4 megas en la base de datos.
Sí se puede hacer con access. Pero tocaría molestarse en averiguar cómo almacenar una copia del archivo en lugar de su representación como mapa de bits. De ese modo:
300 Kb/registro x 200 registros = 60.000 Kb
Access es lo que es y llega hasta donde puede. Que la gente haga malas aplicaciones con Access es otra cosa muy distinta. Una aplicación mal hecha es una aplicación mal hecha.
Re:¡Ojalá fueran todas las preguntas tan sencillas
(Puntos:1)Pues... no es por nada, pero, por más que releo el comentario, no veo por ningún sitio que se considere un "desarrollador experto" (con o sin comillas; me da igual...). Si pudieras iluminarme...
- lo que te sobra es demasiada prepotencia y sobervia.
No creo que eso haya sido un ejemplo de soberbia ni prepotencia. Simplemente ha dicho que un buen "pofesional" de esto, metería los archivos en sistemas de archivos, que para eso se diseñaron.
Que conste que yo no tengo prácticamente idea sobre gestión de bases de datos... pero creo que lo que ha dicho tiene su lógica, aunque también sea cierto que, en algún caso que otro, se puedan incrustar los archivos en la BD.
Disclaimer: No soy el PH al que has respondido :-)
Estoy en contra de la pena de muerte... siempre que no sea yo el verdugo, claro.
Re:¡Ojalá fueran todas las preguntas tan sencillas
(Puntos:1)( http://xperimentos.wordpress.com/ )
En BBDD sus propiedades etc. Y obviamente cuanto más serio y grande en volumen es un entorno de gestión documental, la BBDD NO debe almacenar el contenido.