Re: excepcion en SELECT *

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

In response to

Responses

Browse pgsql-es-ayuda by date

  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 *