database - software - lucidchart generate sql

¿Almacenaría datos binarios en la base de datos o en el sistema de archivos? (11)

Esta es una pregunta que se ha hecho antes ( large-text-and-images-in-sql ) pero principalmente para datos que se cambiarán. En mi caso, los datos serán almacenados y nunca cambiados. Parece sensato mantener todo junto.

¿Hay alguna razón por la que no debería almacenar datos binarios estáticos en una base de datos?

Suponiendo que es algo sensato, ¿hay alguna ventaja de almacenar esos datos en tablas separadas? (Puede comenzar a darse cuenta ahora que no soy un experto en DB ...)

Aclare: probablemente no habrá más de 10-20 usuarios, pero estarán en EE. UU. Y en el Reino Unido. Los datos binarios deberán ser transferidos en cualquier caso.

¿No es esto exactamente lo que se diseñaron LOB o CLOB o ...?

Usamos CLOB para almacenar grandes encriptaciones de transacciones con tarjetas de crédito para un sistema de línea aérea importante.

Sin embargo, el consumo de memoria es tu mayor culpable.

HTH

aclamaciones,

Abordando el problema desde un punto de vista de principios, una base de datos relacional está (principalmente) allí para almacenar datos estructurados. Si no puede realizar una consulta o unirse a un elemento de datos, probablemente no pertenezca a la base de datos. No veo que se use una imagen BLOB en una cláusula WHERE, así que diría que la mantenga fuera de la base de datos. Un CLOB por otro lado se puede utilizar en consultas.

Algunas bases de datos (por ejemplo, Postgresql) comprimen automáticamente los campos, tal vez es más rápido cuando los leen directamente desde db. Y también, el programa puede leer todos los campos y la imagen de una sola vez.

Almacenamos archivos adjuntos en nuestro sistema, y no puede cambiar un archivo adjunto, por lo que creo que estamos en la misma página con datos que "se almacenarán y nunca cambiarán". Específicamente decidimos no almacenarlo en la base de datos. Hicimos esto por dos razones, simplicidad y tiempo de respaldo / recuperación.

La simplicidad es lo primero: en nuestro caso, estos archivos adjuntos se cargan desde el navegador del usuario final, y es más sencillo simplemente escribirlos en un directorio (en el servidor de base de datos) de lo que es para luego transmitirlos por el canal de SQL. Hay un registro de ellos en el DB, pero el DB solo contiene metainformación sobre el archivo adjunto y el nombre del archivo en el disco (un guid en nuestro caso)

En el lado de la copia de seguridad / recuperación: Es probable que estos blobs se conviertan en una de las piezas más grandes de su base de datos. Siempre que ejecute una copia de seguridad completa copiará estos bits una y otra vez, aunque sepa que nunca podrá cambiar. Para nosotros, parecía mucho más simple tener (mucho) copias de seguridad más pequeñas, y hacer una copia del directorio adjunto a un servidor secundario como copia de seguridad.

Creo que esto depende de la aplicación de tu edificio. Si está construyendo un sistema CMS, y el uso de los datos va a consistir en mostrar imágenes dentro de un navegador web, podría tener sentido guardar las imágenes en el disco en lugar de colocarlas en la base de datos. Aunque, sinceramente, haría ambas cosas, lo que podría permitir agregar un servidor a una granja sin tener que copiar archivos por todos lados.

Otro caso de uso podría ser un objeto complejo, como un flujo de trabajo, o incluso un objeto comercial con muchas interdependencias. Puede serializar ambos en un formato binario o basado en texto, y guardarlos en el DB. Luego obtendrá el beneficio de la base de datos: ATOMIC, copias de seguridad, etc.

No creo que la gente deba usar consultas select * en primer lugar. Lo que hace es proporcionar dos formas de obtener los datos, One methods devuelve la información de resumen, la segunda devuelve el blob. No puedo imaginar por qué necesitarías devolver miles de imágenes a la vez.

El problema de rendimiento aquí es la dirección anterior, por lo que no lo repetiré. Pero creo que un buen consejo si está almacenando cosas que se transmitirán mucho (como imágenes / documentos en un sitio web) es construir en un sistema de almacenamiento en caché.

Con esto quiero decir almacenar todos los datos en su base de datos, pero cuando alguien solicita ese archivo, verifique si existe en el disco (basado en un nombre de archivo conocido, en una carpeta temporal); si no, tómelo de la base de datos y escríbalo a la carpeta, y luego transmitir eso al usuario. Para la próxima solicitud al mismo archivo, ya que existe en el disco, se puede servir desde allí sin tocar el DB. Pero si necesita eliminar estos archivos (¡o su servidor web se convierte en kapput!), No importa, ya que se reconstruirán nuevamente desde el DB a medida que la gente los solicite. Esto debería ser mucho más rápido que atender cada solicitud del mismo archivo desde la base de datos.

Estoy familiarizado con un proyecto OSS de bastante buen tamaño que, desde sus inicios, tomó la decisión de almacenar imágenes en la base de datos MySQL, y se ha demostrado que se encuentra entre las 3 mejores ideas malas con las que ha estado lidiando desde entonces. (Acentuado por el hecho de que el "refactor sin piedad" es anatema, pero esa es otra historia).

Entre los serios problemas que esto ha causado:

Exceder el tamaño de base de datos eficiente máximo (mysql). (El espacio total requerido para las imágenes excede a todas las demás por al menos 2 órdenes de magnitud).
Los archivos de imagen pierden su "capacidad de archivo". Sin fechas, etc. a menos que se almacenen (redundantemente) como fechas (que requieren un código para la administración).
Las secuencias de bytes arbitrarios no se procesan bien todo el tiempo, ni para el almacenamiento ni para la manipulación.
"Nunca tendremos que acceder a las imágenes de forma externa" es una suposición peligrosa.
Fragilidad. Debido a que todo el arreglo es antinatural y delicado, y usted no sabe dónde morderá a continuación (contribuyendo a la mentalidad anti-refactor).

¿Los beneficios? Ninguno en lo que puedo pensar, excepto que podría haber sido el camino de menor resistencia en ese momento.

La mayor desventaja si está almacenando BLOBS es el consumo de memoria. ¿Puedes imaginarte qué seleccionaría * de x para miles de registros con una imagen de 45k en cada uno?

Como Mehrdad dijo, también hay ventajas. Entonces, si decides seguir ese enfoque, debes intentar diseñar tu base de datos para que la mayoría de las consultas devuelvan menos resultados con los datos BLOB. Tal vez, por ejemplo, establezca relaciones uno a uno para este propósito.

Quien tuvo la idea de almacenar una imagen (u otro documento binario) en una base de datos no es alguien con quien estoy muy feliz. Las bases de datos están destinadas para el almacenamiento de [¿sobre todo?] Datos INDEXABLES, DISCRETOS. No BLOB de datos binarios sin sentido. Si ha trabajado con BLOB para obtener datos binarios de primera mano, ya lo sabe.

Debe almacenar una referencia al archivo en el sistema de archivos. La mejor práctica es un nombre de archivo, no una ruta absoluta (o incluso relativa).

Toda esta charla sobre hacer un "select * from table" que causa grandes problemas de memoria y / o ancho de banda cuando la tabla tiene un LOB no es un problema. Todo lo que se devuelve es un puntero al LOB en cuestión. No hay suficiente reputación para poner el comentario en contexto, pero las personas que lo miren deben saber que NO es un problema.

La ventaja de almacenar datos en el DB es aprovechar los mecanismos de seguridad del DB y reducir el costo de mantenimiento (copias de seguridad, ...). La desventaja de esto es aumentar la carga de DB y las conexiones consumidoras (que pueden ser costosas para los servidores de bases de datos con licencia por conexión). Si está utilizando SQL Server 2008, FILESTREAM podría ser una buena alternativa.

Por cierto, para las aplicaciones web (o cualquier otra aplicación que pueda necesitar transmitir los datos), generalmente es más sensato almacenar datos fuera de DB.