Re: tipo de dato para los indices

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