limite de registros en una tabla en mysql

[finikini]

ya se que la cantidad de registros en mysql es ilimitado y el tope lo pone el espacio de la maquina, pero...

al margen del espacio, me preguntaba que pasa si tienes una tabla de usuarios con una key primaria tipo bigint auto_increment y esta llega al valor maximo de lo que da ese tipo de campo ¿que pasa? ¿que haces? ¿te jodes y ya no entran mas? ¿abra algun tipo de solucion para eso no?

otra cosa...

al ser auto_increment y se borran algunos registros por cualquier motivo... esos numeros se pierden, se pueden volver a usar de nuevo??? o como ases para que no keden esos huecos...

[Casuis]

Para que te hagas una idea si tienes un campo bigint insertando 100 000 000 de registros al dia, para colapsarlo tendrian que pasar 252 695 124 años. Increible no?? así que no te preocupes que eso no va a pasar.

En el autonumerico los numeros que has borrado se pierden y no se recuperan hasta resetear la tabla.

[santa]

Permítanme acotar algo, en el caso de que un big int no te sea suficiente la idea que se me ocurre es que tu clave primaria deje de ser un entero para pasar a ser un char. Si no estoy loca nada más que el char ingresado tendrá que ser generado por algún proceso. De esta manera con un campo mucho más corto vas a poder tener más cantidad de registros, por ejemplo en Argentina las patentes son por ejemplo [EFT 487] esto te da una combinación de 1 a la 24 en vez de 1 a la 10 obteniendo cantidades inimaginables con tan solo 6 o 10 caracteres.


Saludos y espero haberte dado otra idea mas



La Santa

[gnzsoloyo]

En realidad hay un error en el concepto escrito por santa: Un campo de 10 caracteres, digamos CHAR(10), considerando solamente valores alfanuméricos de la A a la Z, y del 0 al 9, implicaría una combinatoria de 36^10 - 1, esto es: 3.656.158.440.062.975, ya que solamente estamos hablando de 26 letras y 10 números... con el uso de 10 bytes.
En lugar de eso, si usas un BIGINT en realidad usas 8 bytes, ya que los números se almacenan en binario, no como caracteres. Esto significa que para un BIGINT la representación es: 18.446.744.073.709.551.615 . Este valor represente 9.000 veces más valores que con 10 caracteres.
Espero que se entienda la idea: Ante cualquier circunstancia es mejor y ocupa menos espacio, el almacenamiento de un número que el de un caracter, no por las representaciones posibles de un caracter, sino por la forma en que se almacenan los mismos: Un caracter es un Byte, sin importar cuál es. Un número puede ser uno, dos, tres o cuatro bytes, pero en el menor de los casos, su representación es de 255 valores, por cada uno.

El problema de la definición de la clave primaria no tiene relación solamente con que sea numérico, o de caracteres. Tiene que ver con el concepto básico: Una clave primaria es un campo o conjunto de campos que identifica univocamente un sólo registro en una tabla. Cuando no hay un campo o combinación de ellos que lo pueda hacer, entonces es forzoso poner uno numérico incremental o no. Sino, depende de lo que se considere mejor o más útil para el sistema.
Es posible, en contexto de un diseño, que incluso por cuestiones de eficiencia de consultas, sea mejor hacer una clave compleja (varios campos), que poner uno numérico, que no ayudará en la performance de las mismas.

Finalmente, lo que Casius dice es cierto: aún en el peor escenario es difícil que un BIGINT te quede corto. Por lo demás si te resulta insuficiente, es posible que el problema sea un defecto en el diseño del modelo de la base, antes que en la insuficiencia del tipo de campo.