Re: Duda sobre tipo de datos Enteros vs. Caracteres

Gracias a todos por las respuestas.

Para comentarles un poco, estamos en etapa de diseño de modelo fisico y
algunas tablas tienen como clave primaria campos de tipo caracter, porque el
negocio así lo establece, por ejemplo: Nro. de Factura, que generalmente por
negocio esta establecido que es el número de serie con 3 caracteres: 001
(por ejemplo), seguido de un "-" y continua con el número de la factura en
si, que sería: 0000000024, es decir tendría lo siguiente: 001-0000000024 que
suman en total 14 caracteres.

Mis dudas son en cuanto a crear llaves compuestas, pues algunas van a tener
campos de tipo INT y otras de tipo VARCHAR, por ejemplo: cod_empleado y
nro_factura son la clave compuesta de la relación empleado factura (por
citar un ejemplo), y como ya defini que mi campo cod_empleado sea de tipo
INT pero mi campo nro_factura sea de tipo VARCHAR(14) (los dos son claves
primarias de sus tablas respectivas), entonces se crearía mi tabla
empleado_factura con los dos campos como clave primaria (llave compuesta).

Habría algún problema cuando realice una consulta o query?, es decir en
cuanto a rápidez y tiempo de respuesta para una consulta a esta tabla con
clave compuesta y con dos tipos de campos distintos.

Gracias de antemano

On 12/16/05, Gunnar Wolf <gwolf(at)gwolf(dot)org> wrote:
>
> Julio Rivero dijo [Fri, Dec 16, 2005 at 03:23:31PM -0500]:
> > Mi campo cod_empleado varchar(5) not null en mi tabla empleado lo
> utilizo
> > como clave primaria, el Postgresql por defecto me crea un indice,
> entonces,
> > lo que yo tenia pensado era saber si era mas rápido o mejor dicho tener
> > mejor performance en esta tabla teniendo como tipo de variable a mi
> clave
> > primaria de tipo varchar(5)
>
> Piensa en C. ¿Qué tipo de datos es más simple, un entero o una cadena?
> La respuesta es obvia: Es mucho más rápido trabajar con enteros. Y si
> los códigos de empleado son numéricos, no hay ni para qué pensarle: Es
> mucho más rápido manipular enteros. Incluso si los códigos fueran
> mixtos (p.ej. 105935B), sigue siendo conveniente que tu llave primaria
> sea sobre un campo ID entero - Puedes crear además un índice sobre el
> número de empleado, y exigir unicidad con el constraint UNIQUE.
>
> Saludos,
>
> --
> Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)1451-2244 / 5623-0154
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
>

--

Saludos
Att,
Julio Rivero
Movil: 98817321