Campo clave unico en Dif. PC, Como?

[El_Raso]

Que tal a todos...

Estoy desarrollando una aplicacion en Delphi 2010 usando firebird 2.5 con los componentes FIBPlus 6.9.9 y quiero una idea de ustedes de hacer lo siguiente:

Tener una campo clave en una tabla independiente de todos los campos, ya que los datos se digitaran en diferentes laptop offline y luego se uniran en una DB.

He oido habla de un tipo de dato (que ahora no recuerdo el nombre) que son unos identificadores unico, lo he visto en delphi tienen un formato de numeros y letras mayusculas entre {}.

Una manito por favor.

[[Al González]]

Son los identificadores globalmente únicos (GUIDs). En Delphi existen dos funciones que pueden servirte:

CreateGUID, para crear un nuevo GUID, y GUIDToString, para convertirlo a cadena de caracteres si fuese necesario. Ambas se encuentran en la unidad SysUtils.

Espero sea de utilidad, no dejes de comentarnos lo que hagas al respecto.

Saludos.

Al González.

[jhonny]

O también, si es tu preferencia y/o necesidad... puedes trabajar estos números únicos de identificación directamente desde Firebird con sus funciones GEN_UUID, CHAR_TO_UUID y UUID_TO_CHAR.

[guillotmarc]

Por cierto, en la base de datos se guardan en un campo varchar(16) con el charset OCTETS.

[El_Raso]

Empezado por guillotmarc

Por cierto, en la base de datos se guardan en un campo varchar(16) con el charset OCTETS.

Gracias muchachos por responder, una cosa mas, ustedes creen que es conveniente tener una llave primaria varchar(16), no pondra las consultas lentas? o se comportaría igual como los INTEGER?
y por ultimo yo acostumbro a usar el charset win1252 porque uso las Ñ y los acentos ese, como le puedo poner el charset solo al campo llave que comenta guillotmarc?

Le agradezco mucho su tiempo... un saludo.

[Neftali [Germán.Estévez]]

Empezado por El_Raso

...una cosa mas, ustedes creen que es conveniente tener una llave primaria varchar(16), no pondra las consultas lentas? o se comportaría igual como los INTEGER?

Por definición las claves alfanuméricas son "peores" que las numéricas; Tanto para búsquedas, ordenaciones,...
Pero hay que ver si esa pérdida es asumible si realmente lo necesitas. Tal vez para las operaciones y el volumen que tú necesitas no sea apreciable.

Tendrás que "evaluar" los pros y los contras.

[guillotmarc]

Yo no creo que vayas a notar la diferencia a nivel de rendimiento. Total un entero son 4 bytes y estas claves son de 16 bytes, tampoco es que estés sobrecargando de mala manera el sistema.

Donde si vas a notar un gran cambio es en la comodidad de acceder a la base de datos. Y es que para lanzar consultas individuales no es lo mismo la comodidad de consultar el registro 24521 que consultar el registro e3aa1e81-0025-44ee-a83b-83a5a8929d3d

NOTA: Para poner el valor de la UUID en este formato hexadecimal, legible para nosotros, tienes que usar esas funciones CHAR_TO_UUID y UUID_TO_CHAR

Olvídate del rendimiento, eso es lo de menos.

Respecto a como definir un charset específico para unos determinados campos. Puedes definirte, por ejemplo, este dominio en la base de datos. Ahora cualquier campo que definas con este dominio, ya tendrá el tipo y charset adecuado.

Código SQL [-]
CREATE DOMAIN UUID AS VARCHAR(16) CHARACTER SET OCTETS;