Skip site navigation (1) Skip section navigation (2)

Re: tipo de dato para los indices

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Edwin Perez Lozano" <edwinandperez(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: tipo de dato para los indices
Date: 2006-12-21 06:53:22
Message-ID: c2d9e70e0612202253y1a7466ebj90d7960fa10c6dfd@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
On 12/19/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Edwin Perez Lozano escribió:
> > Hola a todos los de la lista.
> >
> > Bueno mis inquietudes son las siguientes:
> >
> > 1.Planeo crear una tabla donde la llave primaria esta compuesta por dos
> > campos varchar(7)( ejeplo; TPO_PER, PER_CON) y estara relacionada con
> > varias tablas en donde creare un indice por la llave foranea, ahora se
> > castiga mucho en rendimiento si manejo este tipo de dato varchar en vez
> > de un entero en un indice?
>
> Se castiga bastante, si.  Algunos sugeririan agregar una columna SERIAL
> y hacer que esa sea la llave primaria, y dejar (TPO_PER, PER_CON) como
> una llave adicional (marcada UNIQUE y NOT NULL).  Otros dirian que eso
> es un sacrilegio y atenta contra las santas reglas de la normalizacion.
>
> Yo estaria de acuerdo con ambos y pondria el SERIAL de todas formas,
> porque no estamos aqui para ser santos sino para entregar soluciones.
>

yo pregunto porque la limitante de 7 caracteres? por lo general,
resulta una mala decision (salvo casos especiales).

te doy un ejemplo en mi ecuador los numeros telefonicos solo tenian 6
digitos dentro de cada area asi que tipicamente la gente declaraba los
campos como char(6)... hoy en dia los numeros telefonicos tienen 7
digitos y ademas porfin hay los famosos numeros
1-800-tufrasepreferida... a corregir diseños y programas...

claro eso es sencillo porque el numero telefonico no lo vas a usar
como PK o FK... pero tu claves posiblemente si las usaras en un FK,
que pasara si te ves obligado a aumentar el tamaño?

mejor declara el campo como TEXT y usa un check para controlar el
tamaño si en realidad lo quieres hacer, sera menos doloroso modificar
el campo...

mejor aun, crea un dominio y usa eso...


> > 2. Tengo el siguiente caso: en una entidad donde el dato primario es un
> > numero que tiene 11 digitos, el dato es un numero de factura, por el
> > momento se tiene planeado manejarlo con bigint dado que tiene mejor
> > rendimiento que un numeric pero esto tendra la desventaja que en varios
> > años el numero sobrepasara lo soportado por el bigint, entonces estoy en
> > el dilema si declarar el campo numeric(n) y castigar el rendimiento o
> > declararlo bigint y cuando llegue el momento hacer un cambio de tipo...
>
> Declaralo bigint y cuando llegues al limite haces el cambio.  Tengo la
> impresion de que el universo se terminara por recalentamiento antes de
> que esto suceda.
>
> alvherre=# select 8500000000000000000::bigint;
>         int8
> ---------------------
>  8500000000000000000
> (1 fila)
>
> Si tienes sucesores suficientes como para sobrevivir hasta el
> recalentamiento, dales mi mensaje de buena suerte en su lucha contra la
> entropia.
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
>        a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
>        a los suscriptores de la lista
>


-- 
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

In response to

Responses

pgsql-es-ayuda by date

Next:From: Manuel TrujilloDate: 2006-12-21 07:39:40
Subject: Re: slony
Previous:From: Jaime CasanovaDate: 2006-12-21 05:49:20
Subject: Re: For loop

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group