Re: excepcion en SELECT *

From: Juan Manuel Acuña Barrera <gps1mx(at)gmail(dot)com>
To: Lista PostgreSQL en Español <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: excepcion en SELECT *
Date: 2011-05-11 17:48:07
Message-ID: 087745E5-F02B-48B1-8EC0-5CA813A080A0@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 11/05/2011, a las 11:15, Alvaro Herrera escribió:

> Excerpts from Álvaro Hernández Tortosa's message of mié may 11 12:02:25 -0400 2011:
>> Wed, May 11, 2011 at 11:56:28AM -0400, Alvaro Herrera escribió:
>
>>> 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.
>
>> 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).

Bueno, en realidad no se añaden nuevas columnas, ya que están contemplados todos los tipos de eventos posibles.
>
> Sí, bueno, a mí me pareció que las columnas _obs_ eran indicadores más
> que eventos. En todo caso estoy de acuerdo contigo en que habría que
> saber más del modelo para saber exactamente qué hacer.
>
>> 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? :)
>
> Sí, de acuerdo.

No hay datos null, ya que por default pone 0 en las claves de observación. En un registro nuevo tendré el id, la fecha y el monto, y unas 7 claves de observación con valores superior a cero y las demás en cero.

En este momento no tengo grandes problemas de rendimiento con estas tablas, ya que el procesamiento completo se hace un par de veces al mes durante la noche y sin usuarios, contemplo la posibilidad de que la cantidad de datos empiece a crecer al punto que ya no sea tan fácilmente manejable. Por eso es que pienso seriamente el hacer pruebas con diferentes esquemas a ver cual me resulta mejor, considerando algo así como 2,000,000 de registros (actualmente tengo algo menos de 600,000 en tres años de operación).

>
> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

Saludos!

Juan Manuel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAk3Ky90ACgkQTc4QiYN6hDeLvgCgq0+uxdOFUBez5C7KfY+VPuLb
MpkAnRB7J76GZP0X+Lh0FLeO1iiRMlto
=OAJU
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Jaime Casanova 2011-05-11 18:10:19 Re: excepcion en SELECT *
Previous Message Mario Raúl Rico 2011-05-11 16:42:09 Re: Consulta de Virtual Machine para PostgreSQL