Acerca de estructura de tablas....

Además de todo lo que te han dicho mi principal problema con ese tipo de
diseño, es que cuando hagas sentencias SQL vas a tener que procesar fila a
fila porque no sabes cual es el contenido de la tabla exactamente.

Lo que tienes que hacer es convencer a la persona del diseño que luego si
hay 1.000.000 de filas tu eres el responsable de que las consultas y los
mantenimientos funcionen.

En vez de tanta tabla dinámica, dile al diseñador que ahora cuando se quiere
incluir información como la que tu tienes, que puede variar, lo que tiene
que hacer es crear un campo cuyo contenido sea XML, de manera que ahí podrás
ser todo lo flexible que quieras. Además la nueva versión de SQL permite
incluir XPATH en las sentencias Transact, ahora tendrías que hacerlo con un
campo tipo text o algo así.

En fin, creo que deberías plantearte un buen documento de queja para
documentar los riesgos a los que os enfrentaréis si seguís con ese diseño.

Salu2 y que la suerte te acompañe


"Eusebio" wrote in message
news:

Hola grupo,


que opinan de crear una tabla en la cual el significado de algunos campos
varíen de acuerdo al contenido de otros.

Por ejemplo, si el campo C1 = 10 entonces el campo C6 se interpretra como
edad, pero si el campo C1 = 11 entonces el campo C6 se interpreta como
número de hijos, etc, etc.

Pienso que es un diseño de tabla nada ortodoxo, el argumento a favor de
quien lo propone es crear un tabla "dinámica"..

No quiero complicarme con una aplicación que maneje una tabla como éstas,

el

problema es que soy el desarrollador de la aplicación.no el diseñador

de

la base de datos...!

Qué opinan...gracias



Eusebio

Si Codd levantará de nuevo la cabeza moriría viendo ese diseño. Las bases de
datos relacionales funcionan mejor si están normalizadas. Eso puede ser
cualquier cosa, menos normalizada... Ahorrate problemas posteriores y
manifiesta tu más enérgica queja. Cada argumento que te den a favor tiene
1000 en contra. Por ejemplo ¿como calcularía el número medio de hijos? o ¿la
edad media?. La respuesta será poniendo where c1, pero eso es una
barbaridad por que cada persona nueva que entre al desarrollo tnedrá que
aprender un montón de numeritos que de nada sirven. el espacio que ocupa un
campo que permita nulos es ridículo, y más en esta era con los tamaños de
los discos duros y el precio de estos.
No hay hoy en día ningún motivo para complicarse la vida con ese diseño.

Saludos

Miguel Egea
Microsoft SQL-SERVER MVP
Brigada Anti-Cursores
http://www.portalsql.com

(Quita el online si me tienes que mandar un correo)


"Eusebio" escribió en el mensaje
news:

Hola grupo,


que opinan de crear una tabla en la cual el significado de algunos campos
varíen de acuerdo al contenido de otros.

Por ejemplo, si el campo C1 = 10 entonces el campo C6 se interpretra como
edad, pero si el campo C1 = 11 entonces el campo C6 se interpreta como
número de hijos, etc, etc.

Pienso que es un diseño de tabla nada ortodoxo, el argumento a favor de
quien lo propone es crear un tabla "dinámica"..

No quiero complicarme con una aplicación que maneje una tabla como éstas,

el

problema es que soy el desarrollador de la aplicación.no el diseñador

de

la base de datos...!

Qué opinan...gracias



Eusebio

gracias a todos.la verdad es que este "diseño" aun no está definido,
pero voy a tener muchos más argumentos para echarlo para atrás!!!!


Eusebio



"Eusebio" escribió en el mensaje
news:

Hola grupo,


que opinan de crear una tabla en la cual el significado de algunos campos
varíen de acuerdo al contenido de otros.

Por ejemplo, si el campo C1 = 10 entonces el campo C6 se interpretra como
edad, pero si el campo C1 = 11 entonces el campo C6 se interpreta como
número de hijos, etc, etc.

Pienso que es un diseño de tabla nada ortodoxo, el argumento a favor de
quien lo propone es crear un tabla "dinámica"..

No quiero complicarme con una aplicación que maneje una tabla como éstas,

el

problema es que soy el desarrollador de la aplicación.no el diseñador

de

la base de datos...!

Qué opinan...gracias



Eusebio