Cita:
Empezado por Al González
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".  |
Exacto, esa es la razón para asignar el ID en el AfterInsert y no en el BeforePost. Puesto que para mantener la relación en los registros maestros-detalles, es muy conveniente tener la identidad del registro maestro nada más crearlo, y no tener que esperar a guardarlo para poder relacionar sus detalles.
Cita:
Empezado por Al González
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. |
Muy interesante observación, alguna vez lo había pensado también pero nunca lo he llevado a la práctica.
Supongo que la ventaja de mantener generadores independientes por tabla es la facilidad de seguir la correlación entre sus registros y sobretodo la facilidad para manejar unos códigos cortos en las consultas manuales que muchas veces te ves obligado a hacer para hacer el seguimiento y depuración de algún módulo.
En cualquier caso nunca había pensado en las ventajas añadidas como la que comentas sobre uniones verticales.
Pero creo que si optas por esa opción, también deberías estudiar la posibilidad de usar UUID's como identificadores de tablas. En las versiones más modernas de Firebird ya vienen funciones integradas que te facilitan enormemente su utilización y obtienes la ventaja añadida de que la unicidad de los ID ya no es solo entre registros de distintas tablas, sino también entre los registros de distintas bases de datos.
Eso es muy útil cuando tenemos bases de datos en distintas localizaciones (por ejemplo un grupo de tiendas que ponen un servidor Firebird local en cada tienda), y que a la vez quieren sincronizar (replicar) periodicamente esas bases de datos. Al utilizar UUID's no tienes que configurar nada en cada base de datos para asegurarte de que generan ID's que no entran en conflicto con el resto del sistema.
Saludos.