los campos autonumericos causan problemas, Mito o verdad?

[Cristo_]

Hola, a todos, pues bien mi duda es la siguiente:

Hay quienes me dicen que cuando uno maneja campos autonumericos, esto causa problemas por que según dicen ellos, esto deja huecos en la base de datos, ya que si manejo autonumericos estamos de acuerdo que tengo el registro 1,2 y 3 y si borro el registro 2 sólo me quedará el registro 1 y 3, pero si doy de alta uno nuevo, me da el 4.

Entonces el hueco que dicen ellos queda, es el registro 2 que jamas podrá ser dado de alta de nuevo, ahora yo no apoyo esta teoría pues si existen los campos autonumericos, es por que funcionan y no para dar problemas, sin embargo me metieron la duda en la cabeza y pues no se que tan real sea esto, de igual forma no he visto nada en internet, ustedes que opinan?

[flaviovich]

Tienes razón.
Los problema surgen cuando uno no sabe usar lo que tiene. Así de simple.

[iislas]

Conclusion: No utilizar IDENTITY, en tablas que sabemos de antemano que van a sufrir DELETE.

simple.......

[abel_c_b]

Iniciado por iislas

Conclusion: No utilizar IDENTITY, en tablas que sabemos de antemano que van a sufrir DELETE.

simple.......

Respuestas como estas son las que ayudan a resolver grandes ........ dudas,

[Beakdan]

Lo de los huecos realmente no es relevante. Los campos tipo Identity son simples claves sustitutas, y como tales puede facilitar la solución de muchos problemas. De la misma forma, emplearlos de manera indiscriminada o en escenarios donde son superfluos, puede acarrearte muchos problemas. Si la preocupación de usar Identity's es derivada debido a que pueden llegar a agotarse los números, puedes comenzar a contar desde el valor más negativo posible para un entero, o elegir un tipo de dato con un mayor rango (BIGINT o NUMERIC).
Donde sí debes preocuparte por la elección de identities, es cuando estés trabajando con replicación en SQL Server.

[Andres95]

buen punto el de usar el mas negativo...


Saludos!

[dlfQuetzalcoatl]

Ninguna de las respuestas anteriores son relevantes, a ver si alguien contesta algo mejor

Saludos !!!

[iislas]

dlfQuetzalcoatl: Si no quieres tener "huecos" en tu tabla donde manejas IDENTITY, ya que esta sufre de DELETE's, simplemente la respuesta es sencilla, NO LOS UTILICES.

Los campos IDENTITY estan pensados para tablas que almacenaran datos, pero que estos, nunca seran borrados.

¿Que es lo que no esta claro?

[Cristo_]

Iniciado por iislas

dlfQuetzalcoatl: Si no quieres tener "huecos" en tu tabla donde manejas IDENTITY, ya que esta sufre de DELETE's, simplemente la respuesta es sencilla, NO LOS UTILICES.

Los campos IDENTITY estan pensados para tablas que almacenaran datos, pero que estos, nunca seran borrados.

¿Que es lo que no esta claro?

lo que no me queda claro es el echo de por que causan problemas, es solo por que se pueden agotar los números de "folio", pues eso de los huecos es solo una idea ya que físicamente el registro ya no se encuentra en ninguna parte de este universo ni en nigun otro

[Cristo_]

Iniciado por dlfQuetzalcoatl

Ninguna de las respuestas anteriores son relevantes, a ver si alguien contesta algo mejor

Saludos !!!

La verdad es que si esperaba mejores respuestas, solo algunas valen la pena

[HackmanC]

Hola,

Aunque es mi concepto personal, a ver si mi respuesta vale la pena :

Posiblemente ...

El problema no creo que sea de eliminar un registro y que quede un hueco disponible, puesto que eso puede suceder inclusive sin usar auto-numéricos; y si deseo ingresar datos en espacios previamente vacíos desordenadamente ... ¿entoces para que los numeré previamente?; es decir, si voy por el numero 1001 y el 2 está vacío, y lo inserto en ese lugar ... ¿de qué me sirvió la numeración?. (Hay que recordar que en una tabla de movimientos no es obligatoria la llave primaria).

El principal posible problema es de concurrencia (como mencionaba alguien anteriormente), es decir, cuando muchos usuarios usan la misma base de datos, puesto que el número 2 que fue 'entregado' a una conexión, posiblemente no sea usado y por lo tanto va a crear un hueco.

Técnicamente ese hueco vendría siendo problemático al momento de usarlo, por ejemplo, con una documentación impresa previamente numerada.

Pero el verdadero problema no es de los auto-numéricos, es de programación y/o malas herramientas de programación, así se puede ver que es un problema sumamente frecuente en sistemas como Microsoft Access (donde el solo hecho de presionar el botón 'Nuevo registro' automáticamente reserva un auto-numerico, inclusive si cancelo posteriormente la operación).

En un excelente diseño de programación, con buenas herramientas, un registro de la base de datos nunca debe ser eliminado, debe quedar un registro permanente por motivos de auditoría y seguridad (solamente se debe marcar como 'anulado'). Si un registro se puede 'eliminar' entonces no era tan importante su numeración.

Pero esa es solamente mi opinión,

Saludos,

[royrojas]

Realmente los autonumericos no son problematicos excepto a como dice iislas que podrian dejar eventualmente algunos huecos en el consecutivo de las tablas.

pero aun asi que importa, no creo que te interese ir viendo registro por registro y que el consecutivo sea relevante, este solo seria un indicador o una llave, la verdad no importaria cual numero lleva.

HackmanC tambien indica algo importante, en lo preferible los datos no se deberian de borrar de la BD, pero tambien sabemos que esto no siempre es asi, aveces hay datos que no son importantes y pues un delete es lo mejor para no llenar de basura la BD.

por rendimiento, si vamos a tener en la tabla un consecutivo, es mucho mas eficiente tener identity que hacer max(id)+1, sql maneja muy bien estos recursos. y por el tamaño del campo, no te preocupes, hay muchos tipos de datos que te van a permitir meter muchisimos registros y no creo que llos llegues a usar todos los numeros.