From: | Álvaro Hernández Tortosa <aht(at)Nosys(dot)es> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Juan Manuel Acuña Barrera <gps1mx(at)gmail(dot)com>, Lista PostgreSQL en Español <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: excepcion en SELECT * |
Date: | 2011-05-11 16:02:25 |
Message-ID: | 20110511160225.GF14460@nosys.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Sergio Gabriel Rodriguez | 2011-05-11 16:12:25 | [OT] Skytools después de que M$ comprara Skype |
Previous Message | Alvaro Herrera | 2011-05-11 15:56:28 | Re: excepcion en SELECT * |