FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
ok, lo se, no pasa nada con los huecos, mi interes era descubrir otras formas y a ser posible mejores (como en todo pa unas cosas si pa otras no).
de todos modos detallare un poco mejor, como dije uso tclientdataset, y en el beforepost es donde obtengo el id via store proc. lo hasigno al campo correspondiente del clientdataset y hago un applyupdates. es por eso que aunque vuestros aportes son magnificos, como dije salvo para casos concretos en que lo haga a mano, no veo como usarlo pues es el propio clientdataset el que genera los insert y no se como recuperar el id o como configurarlo para que lo gestion el. la comodidad que ofrece el clientset (gestiona el solito los insert y los updates y de un modo bastante flexible) me hace pensar que a mi no me vale la pena el beneficio en fin gracias un saludo y muchas gracias |
#2
|
||||
|
||||
Cita:
La base de datos (los triggers) solo le da valores al guardar los datos, por lo tanto, cuando haces relaciones maestro-detalle, no tienes la clave del maestro hasta que no lo hayas guardado (y eso te obliga a recorrer a posteriori los detalles, para asignarles la clave de relación). En cualquier para recuperar el ID, una vez asignado por la base de datos, tienes varias opciones : a) Utilizar la cláusula returning en el INSERT. El problema es que tienes que personalizar la sentencia INSERT con la que se dará de alta el registro, y por lo tanto no puedes usar el ClientDataset para dar de alta el registro. b) Lanzar una consulta : select max(ID) from TABLA, para averiguar el último ID asignado. El problema es que si hay varias personas trabajando a la vez, puedes obtener un valor erroneo. c) Puedes consultar el generador, utilizando un incremento de 0. Es decir : gen_id(NOMBRE_GENERADOR, 0). Esto es más rápido de ejecutar, pero tiene el mismo problema que la solución anterior. Personalmente me sigo quedando con asignar manualmente el ID desde Delphi, en el AfterInsert de un registro. Pero en lugar de utilizar un procedimiento almacenado (más que nada porqué con tanto procedimiento por eso, al final molestan para manejar los que hacen algo "de verdad"), simplemente lanzo una consulta select gen_id(NOMBRE_GENERADOR, 1) from rdb$database Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#3
|
|||
|
|||
ok, muchas gracias por compartir vuestras experiencias. la verdad no conocia la posibilidad de usar la select para lanzar el gen_id en lugar de los procedimientos, si es cierto que es un poco molesto si tienes muchos procedimentos.
nuevamente gracias y un saludo. |
#4
|
||||
|
||||
Cita:
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. |
#5
|
||||
|
||||
Al, los generadores en Firebird son de 64 bits:
Cita:
Un siglo=86400*365*100 segundos = 3156300000 9223372036854775807/3153600000=2924712086 siglos = 2924712 milenios Creo que me he equivocado con los cálculos Enlace a documento sobre generadores. |
#6
|
||||
|
||||
Algo me suponía o había leído, pero (corrígeme si me equivoco) creo que en Firebird 1.5 son de 32 bits. Y bueno, de cualquier manera me referí a los campos ID donde normalmente se guardan estas llaves, que por lo general son de 32 bits, y pensando a futuro, con Firebird 2, cambiar a enteros de 64 bits.
|
#7
|
||||
|
||||
Me parece recordar que en FB1.5 eran de 64 bits, aunque no estoy seguro.
Entonces para lo que indicas puede ser más interesante usar los campos del tipo GUID, esos que son algo así como: 6ef41c55-03ff-4941-9382-290813ad46c2, creo haber leído algo sobre que son aconsejable para lo que comentas y vienen, creo, en FB2.0 en adelante. Aunque todavía no los he visto, puede que me esté confundiendo. |
#8
|
||||
|
||||
Cita:
Si en lugar de quedarme solo con el comentario sobre los enteros de 64 bits, me leyera completos los mensajes, no pasaría estos embarazos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#9
|
||||
|
||||
Cita:
Cita:
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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). Última edición por guillotmarc fecha: 30-04-2011 a las 23:04:25. |
#10
|
||||
|
||||
Cita:
Me parecería bastante conveniente que cada registro de todas las bases de datos del mundo tuvieran un identificador universalmente único, o al menos orientarnos hacia ese ideal empezando a utilizar UUIDs. La duda que me surge es cómo se comportan estos identificadores en cuestión de desempeño, considerando que su tamaño (128 bits) es cuatro veces el de un ID clásico. Saludos. Al González. |
#11
|
||||
|
||||
Cita:
El tema del rendimiento, he leído en varias ocasiones que no tiene ningún impacto notable. Como siempre, es mucho más importante optimizar bien tu consulta (a nivel de índices, plan de ejecución, ...) que no el rendimiento bruto del motor sin optimizaciones. Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Cómo obtener el título del cd insertado? | unreal4u | API de Windows | 4 | 09-07-2007 22:32:13 |
Obtener ID_Direccion recien insertado | Durbed | SQL | 8 | 19-08-2005 02:57:58 |
¿Como leer el registro recien incluido? | sitrico | Conexión con bases de datos | 6 | 30-07-2004 13:44:06 |
Obtener ClaveMaestra del registro insertado. | jplj | Conexión con bases de datos | 11 | 20-05-2004 00:18:33 |
Obtener el último registro insertado | mutant09 | SQL | 3 | 04-05-2004 20:59:21 |
|