Sugerencia de BD en base a funcionalidad

[zyon]

Hola comunidad!

Estaba pensando en hacer un formulario de registro de datos, pero quería que este formulario fuera dinámico, osea que el usuario pudiera definir cuantos campos debe llevar el formulario y además como que guardar estas "plantillas", lo ideal es que le pueda agregar N campos, ya sea entre etiquetas o los propios campos para registrar los datos.

Si me expliqué bien en lo anterior, me gustaría escuchar su opinión sobre como deberías er el diseño de mis tablas en la BD.

Pensé en hacer una tabla que tuviera muchos campos, pero esto obviamente me limitaría el número de campos a definir por el usuario.

La otra es hacer una tabla con los campos necesarios para guardar la configuración de los campos del formulario, pero es generar un registro por campo que agregue el usuario. Este opción me suena mas congruente y práctica.

La segunda opción me gusta más, pero estaba pensando en que también necesito agregar búsquedas (y por lo mismo serían búsquedas definidas por los usuarios y no estáticas) entonces imagino que armar una consulta para búsquedas que cumplan las condiciones en la misma tabla apuntando a los mismos campos, debe ser pesado, por que en primera mano solo me imagino hacer consultar utilizando el UNION.

Me gustaría saber su opinión para darme una idea de que hacer.

Saludos y gracias de antemano!

[ARICARRARO]

Yo creo que no sería bueno que el usuario definiera los campos del formulario.

Yo creo te debe interesar solo algunos datos de tu sus usuarios y no N campos.

A mi me parece que quieres hacer algo similar como los formularios de preguntas en facebook, donde el usuario coloca la pregunta y N alternativas para contestar.

[zyon]

Hola ARICARRARO, en realidad no sabía lo que comentas de facebook, pero creo que si suena genial permitirle al usuario generar sus propios formularios y no hacer una aplicación estática, por ejemplo para encuestas se me ocurre, es por eso que buscaba una opinión sobre que sería conveniente para el diseño de la base de datos que implemente ya que no soy un experto en el tema :/

[gnzsoloyo]

A mi entender estás confundiendo ambos conceptos: la creación de un formulario dinámico con la creación de estructuras de datos dinámicas.
Crear formularios dinámicos no implica usar estructuras de base dinámicas, sino crear una estructura tal que permita la creación dinámica de formularios...
La aplicación y la base son entidades diferentes. La base debe ser lo suficientemente flexible (y no dinámica) para poder cambiar la aplicación sin necesidad de modificar la estructura de datos.
Si generas un excesivo acoplamiento entre ambas, cuando tengas que modificar algún esquema de procesos en la aplicación, la base se vovlerá obsoleta. Y eso es precisamente lo que los arquitectos de datos tratan de evitar.
La base, una vez que entra en producción, no debe ser cambiada salvo por razones de fuerza mayor (cambios de contexto).

[zyon]

Hola gnzsoloyo

Igual no me expliqué, pero si me refería a lo que mencionas:

"Crear formularios dinámicos no implica usar estructuras de base dinámicas, sino crear una estructura tal que permita la creación dinámica de formularios..."

La parte que me preocupa son las busquedas de datos, por eso ando buscando opinión sobre como deberías el el diseño, más que nada en que detalles debo poner más atención.