Wed, May 11, 2011 at 11:56:28AM -0400, Alvaro Herrera escribió:
>Excerpts from Álvaro Hernández Tortosa's message of mié may 11 11:44:57 -0400
>2011:
>> Wed, May 11, 2011 at 10:37:03AM -0500, Juan Manuel Acuña Barrera escribió:
>
>> >> Juan Manuel, con esta información no sé si es el caso, y a lo
>> >> mejor me "tiro a la piscina" mucho, pero si la mayor parte de atributos
>> >> son de tipo cve_obs_*, donde "*" es algo así como un "evento" o similar,
>> >> y teniendo un atributo id como PK, entonces podrías tal vez construir
>> >> una tabla del tipo:
>> >>
>> >> id FK,
>> >> tipo_evento un domain de tipo enum o varchar,
>> >> valor integer,
>> >> PRIMARY KEY(id,tipo_evento)
>
>No sé, esto que sugieres es un esquema de tipo EAV lo cual normalmente
>no es buena idea. Yo creo que la tabla original con 80 columnas puede
>ser una buena solución al problema que tiene.
>
>Considera que cada registro tiene como 24 bytes de sobrecosto de
>almacenamiento debido a las cabeceras de tupla. Si tienes 600000
>registros hay como 14 MB sólo en cabeceras de tupla, pero si tienes
>600000 * 80 hay 47 MB en cabeceras. No necesariamente por ser cada
>registro más corto será más "eficiente".
>
>En suma, si es más eficiente o no va a depender de los patrones de
>acceso y de cómo estén ordenados los registros en la tabla (viz.
>CLUSTER)
Bueno, como he dicho depende mucho del modelo de datos (que no
conozco). Pero estando de acuerdo en el rendimiento, me preocupa
inicialmente más el diseño, y si hay que añadir columnas para cada nuevo
tipo de evento, el problema de mantenibilidad es bastante grande. No
sabiendo seguro que va a existir un problema de rendimiento, prefiero
optar por el diseño (y optimizar posteriormente si fuera necesario).
En todo caso, insisto, depende mucho del modelo de datos, y yo
no sé si los atributos son parte natural del registro o encajan más en
un esquema tipo EAV. El número de datos NULL en todos estos atributos
podría ser un buen indicador, ¿no crees? :)
Saludos,
Álvaro
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
