Gasto de espacio vs. velocidad de acceso

Supongamos que tenemos un archivo para un periódico. Estará compuesto de textos e imágenes (fotos y cartones). Tanto los textos como las imágenes serán de tamaño variable. Como veremos en la sección 14.1.1, PostgreSQL proveé de métodos para almacenar información grande de tamaño variable y lo hace bien. Pero de nuevo, tenemos que tomar en cuenta algunas consideraciones.

La primera es que el tamaño de bloque de PostgreSQL es de ocho kilobytes, lo cual quiere decir que si nuestro texto mide 8 193 bytes, usaremos dos bloques, uno para los primeros 8 192 bytes y el segundo para el byte restante. Esto puede sonar tremendista, pero las probabilidades de que entre miles de objetos (textos, fotos o cartones) sea significativa la incidencia de objetos de tamaño múltiplo de 8KB, es casi cero. Tendremos pues, un gran desperdicio de espacio. Por otro lado, con sistemas operativos modernos como Linux, podemos crear un sistema de archivos en un disco o partición aparte donde optimicemos el tamaño de bloque de tal manera que las pérdidas no sean tan grandes. Esto quiere decir que seguimos teniendo el mismo problema con el sistema de archivos, pero podemos modificarlo de acuerdo a nuestras necesidades particulares, mientras que con el manejador de bases de datos, una alteración similar le pega a las otras bases.

La segunda consideración es respecto a qué nos interesa de la información que almacenaremos en la base de datos. Por supuesto de las fotos y cartones sólo nos interesa hacer búsquedas sobre temas, involucrados, fechas de publicación, etc., es decir, meta información, no el contenido gráfico.

En el caso de los textos, necesitaremos hacer las mismas búsquedas metatemáticas y además sobre algunas palabras clave o incluso texto llano.

Además sabemos que las búsquedas serán discriminadas entre artículos, fotos y cartones. Es decir, la gente que busca las declaraciones hechas por el presidente en Mérida acerca de la política exterior de Madagascar, no le interesa la foto del momento en que lo dijo o el cartón alusivo a lo que dijo. De igual manera, nos interesa la foto de un personaje, pero no simultáneamente el cartón particular del personaje en una situación.

Por otra parte, cada uno de los objetos tienen atributos diferentes, lo cual los hace disconexos en cuanto a información se refiere.

Entonces, el primer diseño que podemos mostrar es el siguiente:

1. cada uno de los objetos en una tabla independiente;

2. naturalmente fotos y cartones no necesitamos que estén en la base de datos, así que pueden quedar en archivos del sistema y con un atributo que nos indique cómo llegar hasta ellos;

3. en el caso de los textos, las búsquedas sobre campos textuales son brutalmente lentos, además de que no tiene sentido hacerlas si las vamos a guardar como BLOBs^4.5, así que para este caso, al momento de procesar los textos, extraemos una referencia a las palabras que ocurren en él --posiblemente eliminando las comunes-- y que quedan almacenadas en una tabla anexa, con lo cuál también eliminamos la necesidad de tener los artículos en una tabla.