Ver Mensaje Individual
  #10  
Antiguo 30-04-2011
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: may 2003
Posts: 5.604
Reputación: 30
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Cita:
Empezado por guillotmarc Ver Mensaje
[...] Personalmente me sigo quedando con asignar manualmente el ID desde Delphi, en el AfterInsert de un registro[...]

select gen_id(NOMBRE_GENERADOR, 1) from rdb$database
Es lo que hago también. Desde el mismo momento en que "nace" un registro en el TClientDataSet, éste ya trae su identificador, es decir, le asigno el ID con el que tentativamente será guardado en la base de datos. Esto por las razones que explicas, Marc. Y es que hasta para existir efímeramente sin ser nunca guardado, resulta útil que un registro tenga su "asa".

También decir que en muchos casos utilizo un sólo generador para todas las tablas, contrario a la costumbre de un generador por tabla. De hecho, al tener cada registro un identificador único, que jamás se repetirá en ninguna otra tabla, se consiguen ventajas interesantes, como hacer uniones verticales sin problemas por duplicidad de IDs y un mayor control en tareas de depuración y manejo de entidades.

A fin de decidir si utilizo o no un sólo generador para toda la base de datos, primero estimo cuántos años necesitaría la aplicación para gastar los 2,147,483,647 IDs que como máximo da en valores positivos un entero con signo de 32 bits (considerando también en ello a los posibles registros cuya captura sea iniciada pero nunca guardada). En la mayoría de los casos, porque no manejo volúmenes de información astronómicos, resulta que no vale la pena usar un generador por tabla.

Claro está, ya me planteo si no sería buena idea comenzar a utilizar IDs de 64 bits, y con ello la aplicación quedaría reforzada contra cualquier usuario increíblemente obsesivo que pase toda su vida apretando constantemente los botones Agregar y Cancelar.

En resumen, debemos quitarnos esa vieja idea de que el campo ID es para numerar registros (para algo así son los campos "NUMERO", "CLAVE", "CODIGO", etc.). El campo ID es para darle unicidad a cada registro de una tabla e identificarlos a nivel interno (el usuario de la aplicación no tiene por qué conocer la existencia de este campo), es la "asa" por la cual se tomarán para su manejo y relación con otros registros, pero no se muestran en ninguna interfaz de usuario o reporte. En pocas palabras, es lo que suelen llamar clave / llave primaria artificial, que no por ser "artificial" es mala, al contrario.

Bueno, ya me explayé demasiado (para variar).

Un abrazo con o sin hueco.

Al González.

Última edición por Al González fecha: 30-04-2011 a las 19:47:04.
Responder Con Cita