Este artículo no pretende realizar un análisis exhaustivo de los tipos de datos blob (objeto binario grande) en SQL Server 2000 (text, ntext e image) por razones claras de espacio y porque en realidad no es ése el objetivo. Me consideraría satisfecho si consigo que cuando se llegue al final, no se tenga miedo a la hora de tratarlos.

Para ser sinceros, mi propia experiencia con estos datos es poca: siempre que por necesidades de la aplicación me he visto en la necesidad de almacenar archivos binarios, he optado por guardar en la base de datos la ruta física de dicho archivo y presentarlo en la aplicación cliente como si fuera el propio usuario el que hiciera doble clic en el icono del fichero. Hasta el momento no me ha ido mal, pero claro, si me ha tocado hacer este artículo, tendré que contaros las desventajas de utilizar el método que os acabo de comentar:

Los datos hay que buscarlos, como mínimo, en dos sitios (la ruta la sabremos a partir de la BD, y a partir de ella tendremos que buscar el archivo).
La administración se complica (por ejemplo las copias de seguridad).
La seguridad se resiente (no podemos utilizar lo que nos proporciona en este sentido SQL Server).
La lógica de la aplicación cliente también se vuelve un poco más enrevesada.
Y en definitiva: si existen unos tipos de datos pensado para ello, ¿por qué no utilizarlos?.

Los tipos de datos Text, nText e Image.

Aunque ya he comentado que no voy a explicar los pormenores técnicos de estos tipos de datos, siempre es bueno comentarlos aunque sea de una manera breve. Si se quiere profundizar más, los Books On Line siguen siendo la mejor herramienta para ello.

Los dos primeros (text y ntext) se utilizan para almacenar cadenas de caracteres superiores a 8000 caracteres o a 4000 en caso de caracteres Unicode; son ideales, por tanto, para el típico campo "observaciones" de la tabla "agenda". Por otro lado, en los tipos de datos image almacenaremos datos binarios superiores a 8000 bytes, es decir, por ejemplo el campo "anexos" de la tabla "documentación". Por el tamaño máximo que se puede guardar no os preocupéis, puesto que 2GB es tamaño más que suficiente, ¿verdad?.

Los que conocéis un poco las tripas de SQL Server, sabréis que el tamaño máximo que puede almacenar en una fila son 8060 bytes. Sin embargo, acabamos de comentar que podemos llegar hasta 2GB… ¿qué ocurre entonces?: pues ocurre ni más ni menos que SQL Server almacena estos tipos de datos fuera de de la fila de datos, conteniendo en su lugar un puntero de texto de 16 bytes que apunta al nodo raíz de un árbol compuesto de punteros internos que asignan las páginas en las que se almacenan los fragmentos de la cadena (extraído directamente de los B.O.L.). Aunque en principio pueda parecer que con lo que estamos tratando es con una cadena más o menos larga de bytes cuando recuperamos el contenido de un campo text, ntext o image, en realidad los datos están almacenados en una colección de páginas de 8KB que no tienen que ser necesariamente contiguas (se organizan lógicamente en una estructura de árbol B).

Existe una nueva opción en SQL Server 2000 que permite almacenar valores pequeños y medianos en una fila de datos (ver tema 'Datos Text in row' en los BOL), lo que hace más rápido su tratamiento. De hecho, activando dicha opción se tratarían como si fueran un campo de texto o binario normal. Ocurre sin embargo que como en este artículo estamos asumiendo que lo que se está tratando de almacenar son cantidades muy grandes de datos, pasaremos por alto este tema.

Su tratamiento.

Bueno, pues todo esto ha sido muy bonito, pero… ¿cómo se manipulan?. Ésta es la pregunta que os estaréis haciendo desde que he comenzado a escribir el artículo (paciencia, pero comprender que tenía que rellenarlo, jejeje). Pues se manipulan, está claro, desde una aplicación cliente; dependiendo de lo que estemos utilizando para acceder al servidor de BD (estamos asumiendo que éste es SQL Server 2000), utilizaremos las diferentes funciones que nos proporcione la librería en cuestión.

En el ejemplo que se adjunta al artículo se está utilizando VB6 como lenguaje, ADO como método de acceso y SQL Server 2000 como base de datos, que es probablemente la combinación más común de todas. Aunque está comentado, os explicaré la metodología que hay que seguir (siempre y cuando queráis utilizar algo similar al ejemplo, claro). En el caso de la lectura, recogeremos el contenido de los campos BLOB (a partir del método GetChunk del objeto ADODB.Field o también gracias a la instrucción T-SQL READTEXT), para ir construyendo un archivo binario temporal; para insertar un campo BLOB, leeremos el contenido del archivo, abierto en modo binario, para irlo insertando en la BD (con método AppendChunk del objeto ADODB.Field o gracias a las instrucciones T-SQL WRITETEXT y UPDATETEXT).

Descarga aquí el ejemplo.

También hay un ejemplo muy interesante en SiquelNet: Trabajando con imágenes en ADO.NET.

Referencias.

MSDN Library Visual Studio 6.0 (temas siguientes)
- AppendChunk.
- GetChunk (ADO).
Libros en pantalla (B.O.L.) de SQL Server (temas siguientes)
- Administrar datos text, ntext e image.
- Datos text, ntext e image cuando text in row es OFF.
- Datos text, ntext e image en desencadenadores INSTEAD OF
- Efectos de los procedimientos almacenados sobre el rendimiento de la aplicación
- READTEXT
- WRITETEXT
- UPDATETEXT
- TEXTPTR
En internet:
- http://www.portalsql.com (web de Miguel Egea y Emilio Boucau. Allí existe otro ejemplo de cómo tratar estos campos).
- http://guille.costasol.net/indice.asp (web del "Guille" sobre VB, con otro ejemplo)
- http://www.microsoft.com/latam/msdn
- http://www.microsoft.com/sql/default.asp

Para cualquier tipo de sugerencia, colaboración o comunicación, diríjanse a

webmaster@helpdna.net