Mantengo una tabla con un ID AUTO INCREMENT PRIMARY KEY. Cuando elimino una entrada y vuelvo a agregar una, la nueva entrada no toma la ID de la anterior sino que se incrementa de nuevo en una. ¿Es eso normal y se aconseja no cambiar este comportamiento? Solo tengo la sensación de que está creando un sistema no escalable, ya que con el tiempo podría quedarse sin índices.mysql incremento automático tecla principal que se está agotando
Está bien. Según la cantidad de registros que espere, puede asegurarse de que sea un tipo bigint, pero int debería estar bien en la mayoría de los casos.
Es normal. No te preocupes porque la identificación sea secuencial.
Depende del número de registros que planea tener y la frecuencia con la que se eliminan y agregan, pero si va a ser un problema, use una clave primaria bigint.
También hay otras opciones, como usar un GUID, si realmente está preocupado por quedarse sin filas, pero nunca me he encontrado con una situación en la que realmente necesitaba un bigint, de vez en cuando los uso en volitle tablas para estar seguro.
No estoy seguro de si MySQL es propenso a esto, pero los GUID pueden ser problemáticos para el mantenimiento del índice. Quizás GUIAS secuenciales? – n8wrl
@ n8wrl - Inherentemente, todas las bases de datos tienen problemas para indexar valores muy aleatorios. Si usa las guías, debe hacerlo de forma secuencial (por ejemplo, una guía COMB) para que sean viables. – Thomas
Esto es por diseño, millones de bases de datos tienen claves primarias como estas con una clave entera.
Si elimina el 90% de sus inserciones, se le acaba de llaves después de 400 millones de filas 1)
Si y cuando lo hace se puede hacer una
ALTER TABLE `test`.`table1` MODIFY COLUMN `item_id` BIGINT UNSIGNED NOT NULL
, ROW_FORMAT = DYNAMIC;
donde la columna item_id haría ser tu llave primaria
Después de eso, nunca más tendrá que preocuparse por quedarse sin espacio de claves nuevamente.
¡No tenga la tentación de comenzar con una clave primaria bigint!
Si sabe que su gran mesa tendrá más filas de las que puede contener el número entero, que por supuesto la haga más grande, pero solo debe hacer esto para las tablas que realmente lo necesitan. Especialmente en tablas InnoDB.
No use un GUID, es solo un montón de espacio desperdiciado, desacelerando todo sin ningún motivo el 99,99% del tiempo.
1) usando un sin firmar! entero como clave principal.
El usuario niceguy07 carga la foto de su gatito. La imagen se guarda como 000.jpg porque utiliza claves principales como nombres de archivo en lugar de poner datos de usuario que no son de confianza en ellos (lo cual es una buena idea).
niceguy07 envía un enlace con? Picture_id = 12334 a su cita.
niceguy07 borra sus imágenes de gatito y el usuario fatperv08 carga una fotografía de sí mismo usando solo una máscara de batman.
Su base de datos reutiliza claves primarias, por lo que desafortunadamente ahora el enlace con? Picture_id = 12334 apunta a una imagen de un pervertido gordo desnudo con una máscara de batman.
La reutilización de los valores de las claves primarias de los registros eliminados es una muy mala idea. Es, de hecho, un error, si las fugas de clave principal fuera de la base de datos porque se utiliza en:
Ya que está, de hecho, muy útil para hacer todo lo anterior, no reutilización de identificadores de clave primaria es una buena idea ...
Tuve que hacer +1 para el ejemplo del mundo real. Algunos administradores no se dan cuenta de las implicaciones hasta que sea demasiado tarde. –
Una clave principal en el diseño de la base de datos debe verse como un identificador único de la información que se está representando. Al eliminar una identificación de una tabla, básicamente está diciendo que este registro no será más. Si algo tomara su lugar, estarías diciendo que el disco volvió a la vida. Ahora, técnicamente, cuando lo quitó en primer lugar, también debería haber eliminado todas las referencias de clave externa. Uno puede sentirse tentado en este momento a decir bien, ya que todos los rastros han desaparecido, de lo que no hay razón por la cual algo no deba tomar su lugar. Bueno, ¿y las copias de seguridad? Digamos que eliminaste el registro por accidente y terminó siendo reemplazado por otra cosa, no podrías restaurar fácilmente ese registro. Esto también podría causar problemas con retrocesos. Por lo tanto, no solo es necesario reutilizar las identificaciones, sino que es fundamentalmente erróneo en la teoría del diseño de bases de datos.
¿Has leído las otras respuestas? –
Sí, pensé que aclararía la naturaleza conceptual de este problema, con suerte, de una manera más completa. – dykstrad
qué tipo de datos entero está utilizando, ¿está firmado o no? http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html –
Tiene razón al hacer la pregunta, ya que he visto que un formulario de exclusión de un boletín deja de funcionar porque ya no podía manejar las solicitudes. –