Duda con CRC32 + 32bits + INT() de Databases

[Skeletron]

Hola gente.
Pregunta media loca:

Sabemos que una base de datos, puede guardar INT(), los cuales, ocupan 4 bytes. o sea: 32 bits.
El numero que se puede guardar en un INT, va de -x a x, pero si lo catalogamos como UNSIGNED, va desde 0 a 4294967295 (ese numero, es 2^32)

OK...
Ahora, tenemo el CRC32, y hay que guardarlo en la base de datos...
CRC32, es un numero de 32 bits.., Por lo que, el numero maximo que puede devolver, es: 4294967295

Tifa, por chat, me dijo que un CRC32, no entra en un INT UNSIGNED.. PERO mi logica dice que SI...
Dios mio.. alguien tiene la respuesta?

[MinusFour]

No estoy muy seguro, pero creo que se debe a la notacion binaria de CRC32...

Porque si por ejemplo, esto es un CRC32 normal...

Código [Seleccionar] Expandir

10000011110111001110111110110111

El número excede por mucho el limite.... si lo tratas de forma decimal, en cambio si convertieras a decimal de seguro te queda algo menor a 4294967295....

Al menos creo yo...

[Skeletron]

Pero.. como que excede?

Si un INT guarda un numero de 32 bits, y el CRC32, devuelve como maximo un numero de 32 bits..
Tiene que entrar!

[MinusFour]

Si, pero a lo que me refiero es que si la base de datos trata el número como decimal, tecnicamente no estas tratando con 32 bits...

sino como 60 bits:

Código [Seleccionar] Expandir

110111100000101101111011011001010100110100000000010111001111

En cambio si lo tratas como decimal, te queda:

Código [Seleccionar] Expandir

2212294583

Que si cabe dentro de los 32 bits.

[Skeletron]

No entiendo a lo que te refieres, porque no va al caso que plantea...

Me dices: "Si la base de datos lo toma como decimal......." Pero.. porque lo va a tomar como decimal? si le pongo INT, tiene que tomarlo como INT:

Tendré que averiguarme por otros medios parece

[^Tifa^]

Skeletron nino    utiliza tu unsigned int si tanto te preocupa, no me hagas mucho caso cuando me haces preguntas sobre numeros y el motivo del porque   

Solo, queria buscarte una salida eficiente a la duda que previamente tenias, lamentablemente no puedo abundarte en relacion a los numeros y los calculos, pero creo que pude responder tu problema inicial 

Como sea, hice una prueba con CRC32 en mi MySQL para ver cuando comenzaba a colisionar (No me aguante la duda  ) hice un bucle con 1 millon de registros dinamicos  y bueno, verifique luego el asuntito de colisiones con CRC32 como indices y que vi... pues el average de colision fue 1% por cada 98,000 registros    lo cual puede ser preocupante si vas a insertar muchas entradas diarias, pero si nisiquiera vas a hacercarte a los 70,000 registros anual obvia todo esto que te digo de las colisiones. Ahora, si quieres evitarte obtener registros duplicados porque colisionen, podrias en tu consulta SQL hacer algo tipo:

Código (sql) [Seleccionar] Expandir

SELECT campo, campo, campo WHERE id = crc32('dato') AND link = 'dato'

Asi aunque existieran colisiones, el registro retornado sera unico siempre 

Al menos claro esta que consideres implementar tu propia hash de 64bits, pero para esto tendrias que rebuscar mucho y truncar el resultado devuelto por MD5() por ejemplo para que no sea tannnn largo el indice. Pero creo, que en tu caso no habra problemas con el uso de CRC32() si todo es como me lo planteaste en cuanto a la actividad diaria, no tendra motivos algunos para colisionar.

Espero, que puedas encontrar tu respuesta que solicitas ahora... como te dije, no me hagas caso cuando te respondo sobre algo relacionado a numeros, utiliza tu UNSIGNED INT si consideras el valor retornado por CRC32() cabe ahi, la prueba siempre podras hacerla antes de definitivamente lanzarte. Que yo utilize DECIMAL no implica que tu tambien lo hagas, entiendo las capacidades que posee tu servidor, en comparacion a las capacidades que poseen el servidor donde he implementado decimal con crc32.

Saludos.

[Skeletron]

Tendré que verificarlo yo mismo parece.
Haré un bucle que pruebe insertar miles de registros, y a ver si alguno se trunca por el INT.