¿que ocupa menos?

[jesusweb]

Voy a crear un campo en la tabla de mysql
cuyos valores seran un numero de 7 a 35 cifras
mas cerca de 35 casi todos, vamos una serie
tipo 12345678912345678912345678912345678

Sé hacerlo tanto usando varchar como double lo que quiero es performance
A lo mejor es una pregunta tonta pero double ocupa mucho menos que varchar no?
Lo digo por lógica ya que por ej
varchar(4) 'abcd' ocupa 5 bytes mientras que smallint ocupa 2 bytes.

Los numeros seran enteros positivos asi que usaré unsigned.
Bueno creo k estoy en lo correcto si hay algún tipo de dato que ocupe menos que
double para mi caso comentenlo porfavor.

[gnzsoloyo]

Un BIGINT UNSIGNED tiene una longitud de 8 bytes y un rango de representación máxima de 0 a 18.446.744.073.709.551.615. No hay columna numérica que pueda almacenar más que eso. Cualquier valor superior debe ser almacenado como FLOAT y ese es un método por aproximación y no precisión.
La pregunta es ¿para qué vas a usar un número que pueda llegar a 12.345.678.912.345.678.912.345.678.912.345.678? (algo que expresaríamos como "doce quintillones")

Por otro lado, ten en cuenta que por más que los puedas alamcenar, no hay lenguaje de programación capaz de manejar semejantes enteros... AL menos en el contexto de lo que yo conozco hasta ahora.

[jesusweb]

Al final resulta que no lo necesito ya que necesito espacios (varchar),

pero si que podrias utilizarlo trabajando con series quiero decir imaginate que por x motivo
tienes que guardar 5 elementos de 5 digitos cada uno vale que puedes crear 5 campos
pero y si solo quieres uno ya que siempres vas a usar los 5 elementos a la vez y no necesitas dividirlos en distintos campos.

En mi caso no es el ej. anterior pero es algo parecido aunque ya lo tengo solucionado me gusta debatir para aprender.
Por organizacion me viene mejor meter todo en un campo.
Supongamos que nos es indiferente meterlo en un campo que en 5 campos distintos
ya que siempre usaremos los 5 campos a la vez.
¿Qué es más eficiente rápido, seguro, mejor...?
Meterlo todo en el mismo campo posteriormente hacer mysql select y luego en php dividirlo en 5 campos.
Meterlo en 5 campos distintos y hacer 5 llamadas a mysql sin tener luego que dividirlo.

Yo me inclino por la primera pero no lo sé por eso pregunto, de todas formas ya he comentado k en mi caso por claridad conviene en un campo.


Entonces si necesitasemos alguna vez guardar un numero grande más de 30 digitos por ej.
Cuál seria la mejor manera? varchar ?

Gracias por tu respuesta gnzsoloyo.

[gnzsoloyo]

pero si que podrias utilizarlo trabajando con series quiero decir imaginate que por x motivo
tienes que guardar 5 elementos de 5 digitos cada uno vale que puedes crear 5 campos
pero y si solo quieres uno ya que siempres vas a usar los 5 elementos a la vez y no necesitas dividirlos en distintos campos.

pareces estar hablando de un campo multivaluado (campo que contiene varios valores diferentes, separados de alguna forma), y los campos multivaluados no existen en los fundamentos de las bases de datos relacionales.
Cuando tienes un objeto X que puede estar relacionado con N objetos, esos N objetos se almacenan en otra tabla y se vinculan ambos con una clave. De ese modo, recuperar el conjunto sólo requiere usar una sola consulta y una función, pero no necesita de malabarismos de diseño de tablas que lo único que te aportan son complicaciones luego, a la hora de las consultas de datos...

Entonces si necesitasemos alguna vez guardar un numero grande más de 30 digitos por ej.
Cuál seria la mejor manera? varchar ?

En primero lugar, deberías definir de qué tipo de dato estás hablando, porque, por ejemplo, un código de barras, que puede tener muchos dígitos, no es por definición un número entero, y un código o clave que se represente con una estructura numérica determinada, no necesaria mente es un número desde el punto de vista matemático.
En cualquier caso, ni los lenguajes de programación son capaces de manejar valores numéricos así, ni tampoco queda claro en qué contexto podrían ser necesarios.
Normalmente, números mayores a 18.446.744.073.709.551.615 no existen en el mundo de los datos humanos. Piensa que ese número, en segundos de tiempo, representa 584.556.957.501,85 años, lo que significa más tiempo que la existencia del Universo.

[jesusweb]

No quiero profundizar mucho en el tema ya que ando mal de tiempo
y no tengo mucho conocimiento.
Cuando dices:

tienes un objeto X que puede estar relacionado con N objetos, esos N objetos se almacenan en otra tabla

Puede ser algo interesante pero no quiero liar la madeja, no hay objeto ni nada
mi pregunta iba enfocada hacia algo más simple.
Imaginate que tienes que trabajar con numeros, un codigo de barras como has
dicho o mejor el nº pi.
Y guardas el nº pi en distintos campos de 50 digitos ¿porque? porque soy un geek jaja, es lo de menos, yo iba al ¿Cómo?
El numero pi esta formado por 0,1,2,3,4,5,6,7,8,9...
Se sobrentiende que pensamos en decimal tampoco vamos a filosofar.
Entonces queremos almacenar grupos de 50 digitos del nºpi, te proponen esto
como programador ¿Cómo lo harias?
En realidad esa es la pregunta que queria hacerte.


Ahora te hago otra
Imaginate que necesitamos los 500 primeros nºs pi ¿porque? porque somos aún más geek jaja
Mas tarde operaremos con todos ellos a la vez divididos en grupos de 50
¿Qué recomiendas almacenar los 500 digitos en un solo campo?
Una llamada, dividirlos y operar.
Almacenarlo en 10 campos, 10 llamadas y operar.
O a lo mejor hay que hacer lo del objeto que me habias comentado y no he entendido.


Si te doy mucha guerra me lo dices y dejo de decir tonterias pero resumiendo
me ha quedado claro que las bases de datos tienen un limite de nºs enteros
de ahi mi pregunta de si se almacenaria en varchar? Esto creo que es una pregunta interesante ¿como guardar numeros de grandes digitos?
Entiendo tu postura de que no puede haber un caso de uso de tal numero y es posible que tengas razon pero bueno como reto, ¿Cómo lo almacenarias?

Respecto a la segunda pregunta no tiene importancia mas alla de la curiosidad pero bueno la fórmulo de otra forma
tienes los siguientes numeros
123456
567890
192834
Solo te interesan los pares
12-34-56
56-78-90
19-28-34
Haras operaciones con los pares
por ej. 12+34*56, 56-34/12
Entonces a mi se me habia ocurrido que en vez de utilizar tres campos para guardar 12,34,56
Guardarlo todo en uno luego dividirlo y operar.
Podriamos decir que ese es un motivo de porque almacenar un nº grande
cuando vamos a operar con subgrupos de este siempre.
Creo que me he explicado bastante bien de todas formas si he dicho alguna
burrada lo siento.