Re: Tipo de datos

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Allirama <aamarilla(at)gmail(dot)com>
Cc: "Alejandro D(dot) Burne" <alejandro(dot)dburne(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Tipo de datos
Date: 2006-09-06 18:43:26
Message-ID: 20060906184326.GF14024@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Allirama escribió:
> Muchas gracias Alejandro, lo voy a tener en cuenta... podría tambien
> utilizar varchar como tipo de campo para la clave principal para que el
> automaticamente gradue el tamaño del campo o no es buena idea?

La representacion de varchar es mucho menos compacta que la de los tipos
de datos como int4 o int8, por diversos motivos. char(N), que mucha
gente cree que es de tamaño fijo, tambien sufre este problema, asi que
no creas que te escapas a ese problema si lo usas (de hecho es mejor no
usar char(N) para nada porque es un tipo de dato totalmente
extravagante).

numeric(N, M) y numeric tambien tienen exactamente el mismo problema.
Usa esos tipos para guardar cantidades (inventario, dinero, etc), pero
no los uses como llaves porque es ineficiente.

int2 te recomiendo no usarlo, porque por motivos de alineamiento, en
muchos casos va a ocupar 4 bytes de todas maneras. Es decir, no ganas
nada y lo unico que consigues es perder espacio de posibles valores.
Usa int4 para casi todo, excepto cuando la cantidad de registros que
puedes llegar a tener excede los cuatro mil millones; en tal caso, usa
int8.

Si tu arquitectura es de 64 bits, es muy posible que tenga requisitos de
alineamiento de 64 bits -- eso significa que en esas arquitecturas,
almacenar un dato de 4 bytes puede tener un sobrecosto por alineamiento
de otros 4 bytes, y por lo tanto, usar un int4 tiene la misma desventaja
que almacenar un int2. No estoy seguro si la plataforma x86-64 (AMD
Opteron, etc) tiene alineamiento de 8 bytes, me imagino que si.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Wdiaz 2006-09-06 20:57:03 Malformed function or procedure escape syntax at offset 1.
Previous Message Ricardo Frydman Eureka! 2006-09-06 18:33:29 Re: Atencion Argentina