Tipo de dato usar por eficiencia

[diablonigromante]

Hola chicos, tengo una tabla que contiene muchos datos de tipo INT y DOUBLE. El tema es que esos datos, digamos que cuando los necesito, el 99% de las veces los necesito por grupos, es decir, imaginaros que tengo 100 campos, pues como ya he dicho, si accedo a la bd para consultar algo, siempre he de acceder para sacar uno de esos grupos por completo.

Grupo 1-[campo1,campo2...campo30]
Grupo 2-[campo31,campo32...campo50]
Grupo 3-[campo51,campo52...campo100]

La pregunta es si hay mucha diferencia entre guardar 100 campos INT y DOUBLE, o guardar 3 campos en el que guardo los 3 grupos como texto, resultado de serializar un array en php.

Dado que se realizan muchas consultas, ¿cual de las dos formas seria mejor para almacenar dichos datos?


Para mas informacion, decir que tenerlo en array me facilita las cosas a la hora de usar los datos.

[gnzsoloyo]

La pregunta es si hay mucha diferencia entre guardar 100 campos INT y DOUBLE, o guardar 3 campos en el que guardo los 3 grupos como texto, resultado de serializar un array en php.

1. En el modelo E-R no deben existir campos multivaluados. Si se tiene un campo multivaluado significa que hay un grave error de diseño en el modelo de datos.
2. los tipos de dato numérico se deben almacenar según su tipo y rango de representación, y jamás en forma de texto por varias razones, entre las que se destacan: a) Usarás siempre más bytes en la base que si los guardaras como dato primitivo, y b) tendrás posibles confliectos de regionalización en la representación de decimales.

Para darte una idea, el número 18446744073709551615 requiere 20 bytes en texto (21 con el signo), pero solamente 8 cuando lo guardas como número, porque en un campo numérico los valores no se almacenan como cifras sino como binarios.

[diablonigromante]

Iniciado por gnzsoloyo

Para darte una idea, el número 18446744073709551615 requiere 20 bytes en texto (21 con el signo), pero solamente 8 cuando lo guardas como número, porque en un campo numérico los valores no se almacenan como cifras sino como binarios.

Eso lo sabía, el problema con el que me encuentro es que son demasiados campos para ir escribiendo selects de 30 campos xD...

Otra idea que tenía, era separar los datos en 3 tablas, la cuestion es que siempre hay un par de campos que son comunes, por lo que para acceder a cada grupo de datos, tendria que hacer primero una consulta a la tabla principal y despues con esos datos a la tabla separada. Se que eso deja mejor diseñada la bbdd, pero la cuestión, sería preferible separarla, en cuyo caso tendria que realizar siempre dos consultas, o es mejor tenerlo todo en la misma tabla?? Sino recuerdo mal, normalizado deberia separla, pero aunque hablas del modelo entidad relacion y todo eso xD...te dire que tengo una vaga idea de E-R y normalizacion, pero eso,vaga xD...asi que perdona si no me explico bien :)

Gracias por tu respuesta.

[gnzsoloyo]

por lo que para acceder a cada grupo de datos, tendria que hacer primero una consulta a la tabla principal y despues con esos datos a la tabla separada.

Lo que describes no es razonable. Si tuvieses esas dos tablas relacionadas por su PK, no necesitas dos consultas, sino una con LEFT/INNER/RIGHT JOIN, con lo cual el problema se soluciona, y en el extremo del caso, si quieres que te devuelva los valores encadenados en un sólo campo, con un separador específico, lo único que deberías usar sería un GROUP_CONCAT, y listo...
En todo caso, si te falta un podo de experiencia en el tema de normalización, postea la estructura de tablas y las relaciones entre ellas, y veremos cómo ayudarte a adaptar el esquema para que sea más eficiente.

[diablonigromante]

Iniciado por gnzsoloyo

Lo que describes no es razonable. Si tuvieses esas dos tablas relacionadas por su PK, no necesitas dos consultas, sino una con LEFT/INNER/RIGHT JOIN, con lo cual el problema se soluciona, y en el extremo del caso, si quieres que te devuelva los valores encadenados en un sólo campo, con un separador específico, lo único que deberías usar sería un GROUP_CONCAT, y listo...
En todo caso, si te falta un podo de experiencia en el tema de normalización, postea la estructura de tablas y las relaciones entre ellas, y veremos cómo ayudarte a adaptar el esquema para que sea más eficiente.

Vaya....ahora lo entiendo ... la verdad que nunca lo había pensado de esa manera. Te postearía la tabla, pero la verdad, la tengo hecha en papel a modo borrador/prueba xD.
La verdad que me dió por hacer la pregunta inicial porque se me planteó hoy mismo, y gracias a ello se me han aclarado algunas cosas más xD.

Te lo agradezco gnzsoloyo, la verdad que hoy me acuesto sabiendo varias cosas más gracias a ti^^.

[gnzsoloyo]

Por nada.
Suerte, y te esperamos de vuelta por acá...