demasiados campos

[PaquitoChocolatero]

Yo creía que no había límite en los campos de una base de datos, o que el límite era muy alto. Sin embargo he recibido el siguiente mensaje al crear una BBDD con 600 campos:

Advertencia: la longitud máxima de la fila supera el límite admisible de 8060 bytes. Para algunas combinaciones de valores grandes, la operación de inserción o actualización no funcionará correctamente.

[Libras]

Creo q te refieres a columnas en una tabla y esto depende del tipo de tabla y del SO pero son mas de 600, ahora el error q te marca esq quieres insertar un valor en una columna q no esta tan grande....

[PaquitoChocolatero]

No se si estoy organizando bien los datos. He pensado un caso similar al real para así exponerlo de forma más clara.

Quiero guardar series de números que vayan de uno en uno, pero quiero guardarlos en texto. Es decir, en vez de "1" quiero guardar "uno", en vez de "2" quiero guardar "dos", etc.

Cada serie está compuesta de un máximo de 100 números. Así que he creado una tabla con 100 campos, llamados Campo1,Campo2,Campo3, etc.

Las series pueden incluir números que estén incluidos en varias series, pero según en qué serie se encuentren tendrán unas propiedades distintas.

Por ejemplo, una propiedad es el orden que ocupan en la serie.

Dado que puedo tener series del 1 al 100, pero puedo tener otra serie del 5 al 105, el número 5 puede tener la propiedad referente al orden que ocupa en la serie de 5ª posición en la primera serie, pero 1ª posición en la segunda. Es decir, según el registro, el dato "cinco" tendrá una propiedad distinta según en qué serie se encuentre.

Así pues, para asignar esas propiedades que varían para cada dato según en qué serie esté incluida... he añadido las propiedades a los campos, y ahora tengo los campos llamados:
Campo1,Campo1Propiedad1,Campo1PRopiedad2,Campo1PRo piedad3,Campo1Propiedad4,Campo1PRopiedad5.
Campo2,Campo2Propiedad1,Campo2Propiedad2, etc.
Así hasta Campo100Propiedad5.
Total: 600 campos.

Luego he pensado que quizás se pueda dividir todos estos campos en 2 tablas, para que cada 1 tenga, por ejemplo, 100 campos y la otra 6 y relacionando las 2 tablas pueda obtener la misma información. Pero no se me ocurre debido a que como digo, puede que el dato "cinco" se repita en varios registros, y en cada registro tendrá unas propiedades diferentes.

En este caso... lo mejor es poner los 600 campos en la misma tabla o hay alguna opción de, con todas estas características, dividir la información en 2 tablas y enlazarlas de alguna manera?

[gnzsoloyo]

Lo que tienes es un profundo desconocimiento de bases de datos.
Para cumplir tus necesidades no precisas seiscientos campos.sino tablas mejor diseñadas, con relaciones correctamente definidas.
Es.muy probable que con menos de media docena de tablas de no más de cuatro campos cada una puedas cubrir la necesidad de tu sistema.

¿Has estudiado o leído ALGO del modelo entidad-relacion?
Porque lo que describes parece mostrar que no.

[iislas]

De acuerdo con gnzsoloyo, mi maestro alguna vez nos pregunto, ¿como modelarian el reino animal en un modelo de entidad-relacion?

Nos quebramos las cabeza y creiamos que serian MILLONES Y MILLONES de entidades y relaciones, al final, logramos entender que con solo una entidad que se apunte a si misma (recursiva), se podria colocar todo el reino animal.

Saludos

[PaquitoChocolatero]

Agradezco a todos el esfuerzo de contestar, pero excepto la 1ª respuesta que, aunque no me resuelve nada si da información útil, las otras respuestas se pueden resumir (descartando las formas) en: "Si no sabes... aprende".

Yo por más vueltas que le doy, pienso que no hay forma de reducir el número de columnas. Y la respuesta de: "si no sabes... aprende" no me sirve.

Yo me pregunto si esos que aseguran con tanta rotundidad "mi ignorancia" sobre el modelo Entidad/Relación sabrían mejorar de forma significativa mi solución.

[gnzsoloyo]

Empecemos por el principio.
¿Tienes claro a que nos referimos con "modelo entidad-relación?
¿Lo has estudiado?

La pregunta apunta a saber cuán detallada tendrá que ser la explicación de la solución, y cual es la base que tienes para poder omitir ciertos detalles.
Por lo pronto, explícanos exactamente qué representa el conjunto de datos que guardas en un único registro dado, si decir , ¿seiscientos datos referidos a Qué? Porque hasta hoy, no he visto jamás una entidad que requiera semejante cantidad de campos para un concepto único.

Pos otro lado, si el objeto es guardar numeros en formato VARCHAR, obviamente en algun momento, dependiendo de como devinas la longitud de los campos, puedes terminar superando no la cantidad de campos posibles, sino la longitud maxima de un registro, que no es lo mismo, y es lo que preguntabas al principio de todo el hilo.
Asi que la pregunta es: ¿QUe es lo que se supone que esa tabla esta intentando representar? ¿QUe entidad o clase de objeto es?

[PaquitoChocolatero]

Gracias a que se ha salido del diálogo y del mensaje anterior, y que el contertulio ha hecho algunas preguntas útiles... me ha hecho pensar y llegar a un nuevo modelo de abstracción mucho más eficiente.

En concreto, la información sobre qué significa cada registro la he podido incluir en un nuevo campo, y la combinación de esa información me hace reducir los 100 distintos campos a 1 solo, y sus 5 características de cada uno de esos 100 a 5 igual. Así que en total ahora tengo 6 campos para recoger la misma información.

Total, que ahora, abstrayendo mi problema de una manera distnita tengo solo 6 campos, y teniendo tan pocas me he dado el lujazo de incluir otras 3 características más, teniendo un total de 9 campos.

Muchas veces no hace falta dar la solución masticada... sino encaminar la solución un poquito.

Gracias por esas preguntas, son las que me han hecho llegar a una abstracción decente del problema.

[gnzsoloyo]

Genial. Me alegro por ti, aunque no has respondido ninguna pregunta.
El feedback suele ser la norma en sitios como este.

[PaquitoChocolatero]

Pongamos un ejemplo más simple de lo que me estaba ocurriendo:

En una base de datos de trabajadores la primera versión de una base de datos se compone de los siguientes campos:

Trabajador1 - sueldo Trabajador 1 - puesto trabajador 1
Trabajador2 - sueldo trabajador 2 - puesto trabajador 2
...
Trabajador 100 - sueldo trabajador 100 - puesto trabajador 100

Para trabajadores de distintas empresas, representando cada registro los datos de los empleados de cada una de las empresas.

Pues el dato que representa cada una de las empresas se puede representar en un campo que se llame "Empresa".

Antes, cada empresa tenia 300 campos, 3 para cada trabajador de los 100 máximos que aguanta la base de datos.

En la nueva versión se reducen de 300 a 3, pero se añade el campo "Empresa", para así diferenciar el Trabajador1 de una empresa de otra. Dando la nueva versión de campos a los siguientes:

Empresa - Trabajador - Sueldo - Puesto.

Lo malo? Tenemos 100 registros para una empresa de 100 trabajadores.
Lo bueno? Pienso que así están mejor indexados y la extracción de trabajadores, para cuando tengamos muchas empresas registradas, será más rápida.
Lo 2º bueno? No tenemos límite en el número de empleados que soporta una empresa en la base de datos. Y si una empresa tiene 50 trabajadores no se desperdician 150 campos (50x3)

Pues algo parecido me pasaba a mí con mi problema real. Solo que no había sabido abstraer mi problema de esta segunda forma.

[gnzsoloyo]

La relación Empresa, Trabajador, Sueldo, requiere de como mínimo tres tablas diferentes, de las cuales la de sueldos es de evolución temporal. Pero podrían ser mas dependiendo de ciertos detalles,solo para esa parte de la relación.
Asimismo un esquema realista requiere de tablas de Categoría, Cargas Sociales, Asistencia y muchas otras más. El esquema final resultante dependerá de un análisis de las necesidades del sistema para esa empresa, aunque estás empezando a acercarte.

La pregunta de si conoces el modelo relacional era porque ese tipo de ejemplos son parte de lo más básico de ese modelo, y no habrías caído en un error de diseño de ese tipo (600 campos), de conocerlo. Encontrarás soluciones para tales cosas en cualquier manual del tema.
Te recomiendo leer los fundamentos de las bases de datos relacionales antes de seguir adelante, para evitar caer en defectos defecto diseño que retrasen tu proyecto, y no tener que inventar el agujero del mate a cada paso. Hay muchas cosas que ya tienen solución definida porque cumplen con ciertos parámetros.