NUMERO MAXIMO DE COLUMNAS CON SQLRDD

[interwin]

Veo que sqlrdd tiene un limte maximo de columnas por tabla.

Cuando tengo una tabla con 208 columnas, sqlrdd manda error al crear la columna del indice INDKEY_004, por lo que asumo que es por un limite en el numero columnas que pueden ser creadas por tabla con SQLRDD .

¿Alguien sabe como ampliar el numero maximo de columnas a manejar con tablas con sqlrdd?. Utilizo base de datos MySQL nativa.

Saludos.

[lucasdebeltran]

Hola,

¿Qué versión de SQLRDD estás usando?.

Saludos

[interwin]

Probe con la version demo mas reciente

Parece ser que el problema en si no es con el numero de columnas si con el numero de indices que se pueden manejar cuando el numero de columnas excede 200: solo se pueden crear 3 columnas para indices sinteticos.

Saludos.

[xmanuel]

La verdad es que no he probado SQLRDD y no sabía de esa limitación. En mi opinión no hay que poner limites...
Peroooooooooooooo si tú tienes una tabla de tantas columnas está teniendo un grave problema de diseño y más pronto que tarde lo pagaras

[interwin]

Manuel

El numero de columnas depende la aplicacion que estes desarrollando. Si mysql admite mas de 4000 columnas por algo a de ser ¿o no?. Por otro lado estoy haciendo pruebas con el demo de sqlrdd como una opcion facil para pasar mis sistemas desarrolllados para trabajar con archivos dbf al entorno SQL Programando estrictamente con los lineamientos de SQL practicamente no es necesario el manejo de indices (de echo deben de evitarse) , pero si se esta traspasando un aplicacion diseñada para entornos DBF aprovechando las facilidades de SQLRDD, los indices se traspasaran tal cuales se definieron al entorno SQL , lo cual desde luego tambien se podria considerar como un error de diseño si lo ves desde el punto de vista de la filosofia del SQL.

Saludos.

[xmanuel]

Sin acritud, aún así pienso que el hecho de que MySql te dé esas posibilidades no implica que sea una buena costumbre utilizarlas.
Efectivamente el uso de indices en SQL es un tema que hay que sopesar cuando se diseña la base de datos porque puede ser una carga más que un alibio.

Por otro lado me imagino que si no le dices a SQLRDD o a la DBF que tiene indices pasará de ellos en la conversión.
Hay muchas utilidades para pasar DBF a MySQL y al contrario por lo que no es necesario usar SQLRDD.
Personalmente creo que implantar la forma de trabajar con DBF+RDD a SQL es un atraso mayúsculo, por muchos motivos. Si te decides por MySQL deberías de usar SQL puro y duro para tus desarrollos.

Es mucho más fácil de manejar tablas de pocas columnas, recuerda que toda la información que necesites tiene que pasar desde el servidor al cliente.
Siempre se puede hacer un select así para recuperar datos de más de una tabla:

SELECT t1.campo1, t1.campo2, t2.campo1, t2.campo2
FROM tabla1 t1, tabla t2
WHERE 1.codigo = t2.codigo

Así podras hacer un join con los datos que necesites.

Pero bueno cada uno se lo curra como le parece, no?

jaja sólo es una opinión lo que vale es lo que funciona!!! por lo menos aquí...