Conveniencia de utilizar BLOB

[Rufus]

Hola.

Estoy leyendo la documentación de interbase 6.0, con la idea de utilizar firebird 1.5.

En el data definition guide alaban las ventajas del tipo de datos BLOB. Una frase concreta que aparece ahí es:

Utilice el tipo de datos BLOB para evitar almacenar punteros a ficheros que no son de base de datos (pg. 76)

Pensando sobre ello, no dudo que los tipos BLOB sean buenos para el caso de textos largos. Pero ¿y para las imágenes? ¿realmente es una ventaja almacenar imágenes dentro de la base de datos, con el consecuente aumento de tamaño que implica, en lugar de almacenar referencias a ficheros de imagen?

[SCORDOBA]

A mi me parece interesante por varias razones. Cuando habalamos de muchas imagenes en archivos separados. (Imaginate un bd de datos documental que tiene 2 milloenes de imagenes, el servidor que almacena 2 millones de archivos en una estructura de carpetas empieza a ser un problema, sobre todo cuando quieres hacer una copia de seguridad).

Otra razon interesante es que puedes usar la conexion cliente para llevar imgenes a usuarios remotos, que el caso de archivos tienes que montar otras historias.

Saludos

[jachguate]

Además, el backup/restore se hace en un solo paso (el de la bd), y se conserva total independencia, incluso, del sistema operativo elegido. Los programas funcionarán exactamente igual con linux que con windows en el servidor (y en este aspecto, en el cliente también).

Desventajas:

Pues que el archivo de la bd puede ponerse muy gordo. Rendimiento, según tengo entendido, no es ningun problema, aunque nunca he experimentado con cantidades astrales de blob's, eso dice la teoria.

Hasta luego.

[Rufus]

Gracias por las respuestas.

Ya había pensado en la ventaja de no tener que "publicar" los ficheros de imagen, asi que mi consulta iba más por el tema del rendimiento. Si en principio no hay problema con eso entonces está bien clara la ventaja de incluir cualquier archivo multimedia dentro de la base de datos.

Ahora lo que no entiendo muy bien es el tamaño de segmento para los campos declarados como BLOB. Según leo, este tamaño es modificable para adaptarlo a lo que se vaya a meter en el campo y lo ideal sería poner un tamaño igual a lo que se almacena, para leer el contenido del campo con sólo leer un segmento. Es decir, que si voy a guardar imágenes las cuales presumiblemente van a tener un tamaño aproximado de unos 200 Kb, ese será el tamaño del segmento. Pero, ¿y en el caso de que no se tenga claro el tamaño de lo que se va a almacenar?, por ejemplo, en el caso de que las imagenes puedan tener 15 kb o 1.500 kb, o en el caso de texto, donde el usuario pueda meter tanto tres palabras como ocho parrafos.

Por último ¿existen funciones para el manejo de texto en BLOB, en firebird 1.5?

[guillotmarc]

Hola.

En otros motores SQL no te recomendaria insertar las imagenes en campos Blob (especialmente no lo recomendaria en SQL Server). Pero Interbase/Firebird se comporta muy bien con estos campos.

No te preocupes por el tamaño de página, no tiene porqué coincidir con el tamaño del Blob. El rendimiento seguirá siendo bueno, aunque deban leerse varias páginas para recuperar el campo. Si tus Blobs són variables, coge un tamaño razonablemente grande (pero no demasiado). Personalmente me parece que 16 kb es una buena elección.

Saludos.

[guillotmarc]

Respecto al manejo de texto y Blobs en Firebird 1.5. Creo que puedes asignar directamente una cadena a un campo Blob dentro de una sentencia INSERT o UPDATE.

Además puedes utilizar funciones UDF. La misma fbudf.dll (que viene con Firebird) tiene funciones para pasar de Blob a String y viceversa.

Saludos.

[BANZAI]

hola tropa
he visto como han hecho referencias al tipo decampo blob, se que ste existe en MySQL pero desconocia su existencia en SQLServer pues tan solo veo de tipo image que me pueden aportar al respecto, es aaso el tipo de blob un plugin que se le agrega al SQLServer?

[kurroman]

Que usais entonces para textos largos? Porque yo suelo usar BLOB y si es mejor cambiar se cambia.