Campo BLOB o imagen en disco

[Gregorio Cíber]

Hola amigos.
Estoy implementando la firma de conformidad, concretamente a la entrega de material una vez confeccionado un albarán de cliente, y se me plantea una duda de qué fórmula sería mejor a la hora de guardar la dicha firma: campo BLOB en la base de datos (Firebird 3.0) o fichero de imagen (jpg,bmp) en el disco.
Como es lógico ambas opciones tienen sus pros y contras y quería saber vuestra opinión al respecto.
Gracias anticipadas.

[cloayza]

Estimado Gregorio Cíber: Si me permite, le daré mi opinión al respecto.

Yo prefiero mantener las imagenes en la base de datos. Los campos blob, nos dan la flexibilidad de poder contener cualquier tipo de archivo. Claro que hay items a tener en cuenta, tales como:

- Que tan grande serán los archivos
- Con cuanta periodicidad serán requeridos en consultas.
- Si son imagenes para un objetivo determinado (Firmas) se podría predefinir un tamaño mínimo y máximo, calidad, todo en pro de tener un mejor rendimiento al requerir este atributo para ser incluido en informes, formularios, etc...

Para despliege del contenido de campos blob que almacenar imagenes existe el componente TDBImage, permite mostrar el contenido (imagen) de estos campos blob, este tiene algunas limitaciones a mostrar solo algunos formatos.

Hace un tiempo modifique un componente imDBJPEG (Fuente) expandiendo la capacidad de desplegar otros formatos de imagenes.

Componente CLDBImagen
Ejemplo de uso lo puede encontrar DLDBImagen Ejemplo

Saludos cordiales

[Gregorio Cíber]

Muy agradecido cloayza por la respuesta. Era precisamente lo que pretendía, que alguien con experiencia en este tema me diera (a todos) su opinión.

Saludos cordiales.

[[movorack]]

Es que siempre "depende de..."

Si es una sola imagen de configuración:

- ¿Con que frecuencia usas o descargas la imagen?
- ¿Con que frecuencia actualizas la imagen?

Ej.

- Logo del aplicativo: Puede que no requieras almacenarlo y puedas distribuirlo como archivo con el aplicativo
- Logo de la compañía que usa el aplicativo: Puede que se modifique muy pocas veces pero se requiera en cada reporte, ahí es posible usarlo desde la DB.

Si son imágenes por registros:

- ¿Cuantos registros y cuantas imágenes calculas se manejaran?
- ¿Tendrás tamaños de peso y dimensiones específicos ?

Ej. Fotos de clientes/empleados/productos

En estos casos, puede que pensarlo como campo de la DB sea fácil pero si con el tiempo tienden a crecer mucho ya sea por cantidad de registros o tamaño de los archivos el proceso de backup puede volverse tedioso.

hasta podrías dejarlo a elección del cliente. Es decir que se pueda con algún parámetro del aplicativo establecer si se almacena en la DB o se almacena en una ruta o algún FTP.

Mi elección, es no enviarlo a la DB. Las imágenes aumentan el tamaño de la base de datos y el backup siempre estará almacenando esas imágenes, aunque una gran cantidad de ellas no cambie.

[Casimiro Notevi]

Empezado por movorack

Mi elección, es no enviarlo a la DB. Las imágenes aumentan el tamaño de la base de datos y el backup siempre estará almacenando esas imágenes, aunque una gran cantidad de ellas no cambie.

Mejor en la BD, así va todo ahí y no se pierde nada.


Distinto sería que fuesen montones de imágenes enormes, e incluso así habría que pensar en los pros y contra.
Siempre seré partidario de incluirlas en la BD, salvo casos muy específicos.

[Gregorio Cíber]

Gracias de nuevo por responder.

El tamaño de cada imagen será siempre el mismo y no muy grande. Sólo se cargarán cuando se impima el documento.

En cuanto al número de registros implicados sí será considerable. Hay que tener en cuanta que se trata de una actividad de venta por distribución (muchos albaranes de pequeñas cantidades) y cada albarán puede llevar su firma. En el ejercicio pasado fueron alrededor de 25.000 albaranes.

También había pensado en lo que dice [movorack], es decir, ponerle una opción al cliente en la ficha de la empresa y que sea él el que tome la decisión.

[Casimiro Notevi]

Empezado por Gregorio Cíber

En el ejercicio pasado fueron alrededor de 25.000 albaranes.

Puedes estar tranquilo, eso no es nada, a veces he contado de "viejos" clientes que tienen bases de datos de cientos de gigas con tablas de cientos de millones de registros.

[[movorack]]

Como ya dije antes: "Depende de..."

En este articulo tienes los pros y contras de usar cada método.

File System vs. Database

Sistema de archivos
Veamos algunos pros y contras involucrados en guardar archivos en el sistema de archivos.

Ventajas del sistema de archivos

• El rendimiento puede ser mejor que cuando lo haces en una base de datos. Para justificar esto, si almacena archivos grandes en la base de datos, puede ralentizar el rendimiento porque una simple consulta para recuperar la lista de archivos o el nombre de archivo también cargará los datos del archivo si utilizó Select * en su consulta.
• En un sistema de archivos, acceder a un archivo es bastante simple y ligero.
• Guardar los archivos y descargarlos en el sistema de archivos es mucho más simple que en una base de datos, ya que una simple función "Guardar como" lo ayudará. La descarga se puede hacer dirigiendo una URL con la ubicación del archivo guardado.
• La migración de los datos es un proceso fácil. Simplemente puede copiar y pegar la carpeta en el destino que desee y asegurarse de que se proporcionan permisos de escritura en su destino.
• Es rentable en la mayoría de los casos expandir su servidor web en lugar de pagar por ciertas bases de datos.
• Es fácil migrarlo al almacenamiento en la nube, es decir, Amazon S3, CDN, etc. en el futuro.

Contras del sistema de archivos

• Vagamente embalado. No hay operaciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) en el mapeo relacional, lo que significa que no hay garantía.
• Considere un escenario en el que sus archivos se eliminen de la ubicación manualmente o por algunos tipos de hacking. Es posible que no sepa si el archivo existe o no. Doloroso, ¿verdad?
• Baja seguridad. Ya que sus archivos se pueden guardar en una carpeta donde debería haber proporcionado permisos de escritura, es propenso a problemas de seguridad e invita a problemas, como la piratería. Es mejor evitar guardar en el sistema de archivos si no puede darse el lujo de comprometerse en términos de seguridad.

Casos de uso
Si su aplicación es responsable de manejar archivos grandes (es decir, más de 5 MB) y la cantidad de archivos que se cargan.
Si su aplicación tendrá una gran cantidad de usuarios.

Diverso
Aunque el sistema de archivos tiene algunos costos y ciertas desventajas, una buena estructura de carpetas internas y la elección de una ubicación de la carpeta a las que los demás pueden ser un poco difíciles pueden ayudar.

Base de datos
Veamos algunos pros y contras involucrados en guardar archivos en el

Ventajas de la base de datos

• La consistencia de ACID, que incluye una reversión de una actualización que es complicada cuando los archivos se almacenan fuera de la base de datos.
• Los archivos estarán sincronizados con la base de datos y no podrán quedar huérfanos, lo que le da la ventaja en el seguimiento de transacciones.
• Las copias de seguridad incluyen automáticamente archivos binarios.
• Es más seguro que guardar en un sistema de archivos.

Contras de la base de datos

• Es posible que tenga que convertir los archivos a blob para almacenarlos en la base de datos.
• Las copias de seguridad de la base de datos serán más pesadas y pesadas.
• La memoria es ineficaz. A menudo, los RDBMS están controlados por RAM, por lo que todos los datos deben ir primero a la RAM. Sí es cierto. ¿Alguna vez has pensado en lo que sucede cuando un RDBMS tiene que encontrar y ordenar datos? RDBMS rastrea cada página de datos, incluso la cantidad más baja de datos leídos y escritos, y debe rastrear si está en la memoria o si está en el disco, si está indexada o si está ordenada físicamente, etc.

Nota: omití algunos puntos contradictorios para restringir el contenido porque al comparar dos cosas, a menudo terminamos encontrando que los pros y los contras de una son opuestos a los otros.

Casos de uso
Si el archivo de su usuario necesita estar más estrechamente acoplado, protegido y es confidencial.
Si su aplicación no exigirá una gran cantidad de archivos de una gran cantidad de usuarios.

Diverso
Tenga cuidado con su consulta de selección. Evite consultas Select * no deseadas, que con frecuencia pueden recuperar los datos del archivo innecesariamente. El almacenamiento en caché de los datos del archivo puede ayudar a reducir el uso de la memoria y la base de datos.

Si está utilizando SQL Server 2008 o una versión superior, utilice Filestream. Filestream permite almacenar datos de blob en NTFS al tiempo que garantiza la coherencia transaccional entre los datos de blob no estructurados con datos estructurados en DB.

Para explorar más sobre Filestream, consulte este enlace.

Puede que te des cuenta de que aún no he dicho cuál es la mejor opción. La respuesta es que depende.

Sé que esa respuesta puede ponerlo furioso, pero honestamente, la clave está en analizar sus necesidades y anticipar los peores casos de antemano.

Basándonos en los requisitos de nuestros productos, en Habile optamos por el sistema de archivos cuando manejamos cantidades masivas y archivos pesados, y vamos a la base de datos en los casos en que tenemos más archivos ligeros y menos.

Sin embargo, adaptarse a la función Filestream del servidor SQL 2008 podría ser una buena prueba. Entonces, en Habile hemos iniciado la incorporación de Filestream. Le recomendamos que haga lo mismo si puede pagarlo.

Porque en el mundo de la supervivencia de Fittest, es importante utilizar la tecnología a su máximo potencial.