Cuando guarda sus imágenes (supongamos que tiene muchas), ¿las almacena como manchas en su Base de datos o como archivos? ¿Por qué?Guardar imágenes: ¿archivos o blobs?
Duplicado de: Storing Images in DB - Yea or Nay?
suelo ir con almacenarlas como archivos y almacenar la ruta en la base de datos. Para mí, es un enfoque mucho más fácil y más natural que insertarlos en la base de datos como blobs.
Un argumento para almacenarlos en la base de datos: mucho más fácil hacer copias de seguridad completas, pero eso depende de sus necesidades. Si necesita poder tomar fácilmente instantáneas completas de su base de datos (incluidas las imágenes), almacenarlas como blobs en la base de datos es probablemente el camino a seguir. De lo contrario, debe vincular la copia de seguridad de su base de datos con una copia de seguridad de archivos y de alguna manera tratar de asociar los dos, de modo que si tiene que hacer una restauración, sepa qué par restaurar.
Si estoy ejecutando en un servidor web y solo se ejecutará en un servidor web, los almaceno como archivos. Si me estoy ejecutando en varios sitios web, pongo la instancia de referencia de la imagen en una base de datos BLOB y la guardo como un archivo en los encabezados.
Depende del tamaño de la imagen.
Microsoft Research tiene una interesting document sobre el tema
El resumen de ese documento fue que el sistema de archivos (ntfs) tiende a funcionar mejor con archivos de más de 1 mb y el db funciona mejor con archivos de menos de 1 mb (cuanto menor, mejor). – sjdirect
Que el documento es de 2006, eso es hace 11 años por ahora. Entonces hoy las cosas podrían ser diferentes. Y, de hecho, la conclusión es: "(...) si los objetos son más grandes que 1 MiB en promedio, NTFS tiene una clara ventaja sobre SQL Server.Si los objetos están por debajo de 256 KiB, la base de datos tiene una clara ventaja. Dentro de este rango, depende ... " –
gotas puede ser pesado en los db/scripts, por qué no sólo almacenan caminos. La única razón por la que hemos usado blobs es si necesita fusionarse con seguridad replicada o súper estrecha para los activos (como en la imagen de extracción a menos que haya iniciado sesión o algo)
Para usted punto, necesito" seguridad súper estricta ". Así que creo que una gota para documentos seguros como declaraciones de impuestos sería lo mejor, ¿no? Entonces todos los elementos no seguros como imágenes, etc. , podría estar en una carpeta de archivos? – user982853
Dado que es posible que desee guardar una imagen junto con un nombre, una breve descripción, una fecha de creación, una creación de, etc., es posible que sea mejor guardarla en una base de datos. De esa manera, todo está junto. Si guardó esta misma información y almacenó la imagen como un archivo, tendría que recuperar todo el "objeto de imagen" de dos lugares ... y más adelante, es posible que tenga problemas de sincronización (no se encuentran algunas imágenes) . Espero que esto tenga sentido.
Al guardar, ¿quiere usarlos para mostrar en una página web o algo así? Si es el caso, la mejor opción será usar archivos; si utiliza una base de datos, se la martillará constantemente con la solicitud de fotos. Y es una situación que no se escala demasiado bien.
No hay imágenes. Estos son solo documentos relacionados con transacciones, por lo que no se extraería nada cada vez que alguien visitara el sitio como un logotipo o algo así. Estos son documentos del cliente y el único momento en que se eliminarían sería cuando el profesional o el cliente intentan verlos. – user982853
He intentado usar el db (SQL Server y MySQL) para almacenar archivos medianos (< 5mb), y lo que obtuve fue un montón de problemas.
1) Algunos DB (SQL Server Express) tienen límites de tamaño;
2) Algunos DBs (MySQL) se vuelven mortalmente lentos;
3) Cuando tiene que mostrar una lista de objetos, si inadvertidamente selecciona SELECT * FROM table, toneladas de datos intentarán subir y bajar desde la base de datos, dando como resultado una respuesta lenta letal o un error de memoria;
4) Algunas interfaces (ActiveRecord de ruby) tienen problemas muy grandes para manejar blobs.
Solo use archivos. No los guarde todos en el mismo directorio, use alguna técnica para colocarlos en varios directorios (por ejemplo, podría usar los dos últimos caracteres de un GUID o los últimos dos dígitos de un ID int) y luego almacenar la ruta en db.
Me vendiste en 'SELECCIONAR * DE la tabla' - Lo uso periódicamente para fines de prueba y solo eso podría causarme un gran dolor de cabeza. ¡Archivos para mí! – rybo111
La pregunta es, ¿su aplicación maneja BLOBS u otros archivos como otros datos de la aplicación? ¿Sus usuarios cargan imágenes junto con otros datos? Si es así, entonces debe almacenar los BLOB en la base de datos. Hace que sea más fácil hacer una copia de seguridad de la base de datos y, en caso de un problema, recuperar un estado consistente en transacciones.
Pero si se refiere a imágenes que son parte de la infratstructure aplicación en lugar de los datos de usuario a continuación, probablemente la respuesta es, No.
El impacto en el rendimiento de un servidor de base de datos es una cuestión discutible. Si necesita los beneficios de rendimiento de un sistema de archivos, simplemente almacénelo allí en la primera solicitud. Las solicitudes posteriores pueden ser atendidas directamente desde el sistema de archivos por un enlace directo (que, en el caso de una aplicación web, podría reescribir el HTML antes de descargar el búfer de salida).
Esto proporciona lo mejor de ambos mundos:
No hay necesidad de martillar constantemente la base de datos para cosas que no cambiarán todo el tiempo, pero lo importante es que los datos del usuario están allí y no dispersos por diferentes lugares, haciendo que el servidor funcione y despliegue un desastre total. Siempre estoy defendiendo el enfoque de "base de datos como almacén de datos del usuario, a menos que", porque es mejor arquitectónicamente y no necesariamente más lento con el almacenamiento en caché efectivo.
Habiendo dicho eso, una buena razón para usar el sistema de archivos como tienda autorizada sería cuando realmente necesita usar herramientas independientes externas para acceder a ella, p. SFTP y otras cosas.
si tiene una aplicación web, los archivos son el camino a seguir, construye el HTML con la información de ruta de la base de datos que apunta al archivo que está almacenado desde donde lo desplegará el navegador del cliente. –
Estoy construyendo una aplicación fuera de línea. Descubrí que almacenar el blob permite una fácil replicación de la base de datos. ¡Solo un pensamiento! –
Escribí un pequeño sistema de envío y pegué las imágenes en la base de datos. Una vez que alcanzó un gran tamaño, las copias de seguridad de la base de datos se volvieron muy problemáticas (30,000 imágenes). Finalmente, la base de datos y cualquier consulta que devuelva las imágenes se detienen. El motor SQL del motor de base de datos tenía problemas serios y tuvo que borrar el caché de consultas para solucionarlo. Al final finalmente lo refactoré. Agregar un poco de administración de disco valió la pena y nunca volveré a pegar una imagen en una base de datos de SQL Server. – Skarsnik