Diferencia de "peso" entre variables de MySQL

Iniciado por Skeletron, 9 Agosto 2009, 02:08 AM

0 Miembros y 1 Visitante están viendo este tema.

Skeletron

Hola gente..
Tengo una gran duda... Enorme duda... Pero facil de responder (espero)

Supongamos que en una tabla MySQL tengo que "anotar" numeros...

El largo de éste numero es de 1350 caracteres (aunque estoy intentando achicar esa cantidad).. o sea. un numero SUPER LARGO :)
Me dijeron que me conviene agregarlo como una variable numerica Binaria.. para ocupar mucho menos espacio en disco (ya que de estas entradas, tendre que agregar unos cuantos millones)

La pregunta es:
Lo guardo en tipo INT y atributo binario?
Para guardarlo de esa manera, tengo que "enviarle" el numero en binario?? o a la transformacion la hace MySQL?

SnakeDrak

Hola,

Decide tu lo mejor mirando la referencia:

http://dev.mysql.com/doc/refman/5.0/es/numeric-types.html

Aquí también tienes una buena explicación:

http://www.desarrolloweb.com/articulos/1054.php

Ojalá te sirva!

Saludos!

Skeletron

O sea que los campos numericos son PEQUEÑOS en relacion de lo que yo necesito... Tendré que dividir ese numero MUCHAS VECES para meterlo en varias entradas :o

[u]nsigned

Creo que sería más factible meter el dato en un ampo tipo text, que puede almacenar hasta 60.000 caracteres aproximadamente.  :silbar:

Saludos

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

Skeletron

Ahora imaginate el peso en "KB" que llevaria eso nsigned

rigoxls

Saludos, bueno encontrar una buena solucion para ese problema siempre va a tener sus pro y sus contras....

Lo que dijo [ U ]nsigned pues si lo miras por el lado de que es un campo de texto y te va aguantar la capacidad de los 1350 caracteres que indica estaria bien...

El peso si va aumentar como indicas, pero igual depende del lado que lo mires, por ejemplo, cada tema que abren en este foro en promedio supera esa cantidad de caracteres para un campo de texto, ....

Otra forma seria que comprimieses los datos antes de insertarlos a tu bd...
Pero ahi si te tocaria ingeniar un tipo de compresion especial para tu datos y evitar guardar toda la cadena de caracteres numericos....

No hay verdades absolutas sin ciegas posiciones !!!

[u]nsigned

Cita de: Skeletron en 10 Agosto 2009, 00:06 AM
Ahora imaginate el peso en "KB" que llevaria eso nsigned

Si vasa a guardar varios millones de registros con números de 1350 caracteres no esperes usar 'un par de megas' nada más.. :silbar:

No conozco tanto de SQL, pero no se me ocurre otra forma de guardar un número tan grande  :P

Saludos

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

Skeletron

Lo que tengo en mente es elavorar un HASH.. Algo bastante inteligente y que sea optimo...
Cuando se me ocurra algo, les comento..

[u]nsigned

El problema con la compresión, y mas aun de un número, es que todos los HASH que reducen el peso son digest NO REVERSIBLES.

La verdad que partiendo de una variable xxxxxxxxxxxxxxx y luego obtener una yyyy, desde la cual se pueda volver a obtener xxxxxxxxxxxxxxx sería toda una revolución. Bueno, no tan así, habría que ver como trabajan los algoritmos de compresión de archivos (RAR o 7z), que supongo trabajan a nivel de BITS..es algo que siempre me interesó, pero la verdad nunca le dediqué tiempo, y supongo que no debe ser nada simple..y mas aun para alguien con practicamente 0 conocimientos de criptografía como yo... :-\

Saludos y perdon por el off-topic.. :xD :)

No hay atajo ante la duda, el misterio se hace aquí...
Se hace carne en cada uno, el misterio es existir!

Skeletron

SI teno un numero XXXXXXXXXXX y lo divido por un numero YYY, dará un resutaldo ZZZZ, que dependiendo cual sea el valor de YYY el resultado Z se puede TRUNCAR para lograr un menor espacio..