Campo Llave grande en Firebird

[jorosmtz]

Buen día, una pregunta, estoy desarrollando una aplicacion en la cual se van a crear registros únicos en varios lugares (se piensa vender el software con miras a consolidar algún día las BD's).

Tengo el campo llave en el cual pienso poner una serie de datos concatenados haciendo una cadena de posiblemente 10 caracteres, tipo RFC o CURP en México.

¿Sería correcto hacer esto? ¿No son demasiados caracteres para un campo llave lo cual vuelva lenta la búsqueda?

P.D. Estoy iniciando con Firebird y no se como funcione, por eso la pregunta.

[marcoszorrilla]

No creo que 10 caracteres sea un campo grande para crear una PK.

Un Saludo.

[[duilioisola]]

Tienes más opciones:
Crear un campo ID integer que sea PK y se autoincremente y luego crear los diferentes campos y unirlos en un indice unívoco.

Código SQL [-]
CREATE TABLE MI_TABLA
(
ID INTEGER,
CAMPO1 INTEGER,
CAMPO2 VARCHAR(5),
CAMPO3 VARCHAR(3)
CAMPO_DATO1 
CAMPO_DATO2
CAMPO_DATO3
...
);

ALTER TABLE MI_TABLA ADD CONSTRAINT PK_MI_TABLA PRIMARY KEY (ID);

CREATE UNIQUE INDEX GD_DOCUMENTO_IDX1 ON GD_DOCUMENTO (CAMPO1, CAMPO2, CAMPO3);

Esto te permitirá luego hacer busquedas por solo uno de los campos. Deberás tener en cuenta que deberías hacer un índice apropiado para esta búsqueda.

También puedes crear la PK directamente de los campos que necesites:

Código SQL [-]
ALTER TABLE MI_TABLA ADD CONSTRAINT PK_MI_TABLA PRIMARY KEY (CAMPO1, CAMPO2, CAMPO3);

[[RONPABLO]]

Mira sobre lo que hablan acá

[[Lepe]]

En mi opinión, Usaría un campo BigInt como clave primaria (que será en delphi un Int64).

Dicho campo no tendría ningún significado para la lógica de negocios, es decir, ese número no se usa en número de facturas ni en nada de nada, únicamente sería para identificar un registro, nada más. Así puedes cambiar el valor, borrar maestros y detalles sin problemas y sin afectar a la numeración de facturas y esas cosas.

[[RONPABLO]]

Dicho campo no tendría ningún significado para la lógica de negocios, es decir, ese número no se usa en número de facturas ni en nada de nada, únicamente sería para identificar un registro, nada más. Así puedes cambiar el valor, borrar maestros y detalles sin problemas y sin afectar a la numeración de facturas y esas cosas.

El problema con esta solución podría ser que cuando dice:

se van a crear registros únicos en varios lugares (se piensa vender el software con miras a consolidar algún día las BD's).

Es que van a trabajar con varias bases de datos en diferentes computadores (puede ser o no en diferentes sedes) y con el tiempo las van a integrar (de forma permanente o no) en una sola base de datos, al tener una llave primaria autoincrementada es muy probable que en las diversas bases de datos se cree el valor "1, 2, 3, 4, 5" y ahí a la hora de integrar va a tener problemas de llave primaria y otros problemas que se dan al integrar, por eso el propone el char de tamaño 10, aunque lo recomendable y más estandarizado en estos casos es usar llaves primarias GUID, en el enlace que envié en mi comentario anterior explican como usarlos y como crearlos.

[jorosmtz]

Gracias a todos muchachos, y gracias RONPABLO por el link al otro post, muy ilustrativo. Por lo que leí no le afecta a la búsqueda que el campo llave sea alfanumerico y grande. Para el campo llave he decidido concatenar algunas cadenas de la siguiente manera:

- Primeras dos letras del nombre.
- Primeras dos letras del apellido paterno
- Primeras dos letras del apellido materno. Si no tiene apellido materno (aquí en México hay casos) se ponen dos "x" en su lugar.
- Fecha de nacimiento con formato ddmmyyyy
- Una letra del alfabeto empezando por la letra "A" (caracter extra para evitar duplicados). Si esta combinación ya existe el caracter extra se va incrementando de acuerdo al alfabeto.

De esta forma el campo llave quedaría como una cadena alfanumerica de 15 caracteres.