Modelo de datos para un formulario web extensible.

Question

Supongamos que tengo un formulario que contiene tres 10 campos:campo1..campo10.Almaceno los datos del formulario en una o más tablas de la base de datos, probablemente usando 10 columnas de la base de datos.

Ahora supongamos que unos meses después quiero agregar 3 campos más.Y en el futuro podré agregar/eliminar campos de este formulario según los requisitos cambiantes.Si tengo una columna de base de datos por campo de formulario, entonces tendría que realizar los cambios correspondientes en la base de datos cada vez que cambie el formulario.Esto parece un dolor de cabeza de mantenimiento.Debe haber una manera más sofisticada.

Entonces mi pregunta es, ¿cómo diseño un modelo de datos que esté ligeramente acoplado con mi interfaz de usuario?Un caso de uso concreto es un sistema CRM que los usuarios pueden ampliar/personalizar.

Answer 1

A menos que tenga una muy buena razón para hacer esto, generalmente es una mala idea.Hace que sea muy difícil optimizar y escalar la base de datos.

Si es absolutamente necesario hacerlo, entonces la sugerencia de Travis está bien para mesas pequeñas, pero en realidad no se ampliará tan bien.

Answer 2

Puede abstraer campos en una tabla separada para que sean muchos a muchos en la tabla Formulario:

Forma

IDENTIFICACIÓN
Nombre
etc.

Campo

IDENTIFICACIÓN
Etiqueta
Valor

Campo de formulario

ID de formulario
ID de campo

Answer 3

A mi equipo se le ocurrió una solución para esto cuando trabajaba para Quest Computing en AIMS (www.totalaims.com).En resumen agregamos pantallas de mantenimiento que permitieron al administrador agregar metadatos y también como resultado agregar campos a la base de datos en ciertas tablas.Los campos también se agregaron automáticamente a sus propias pantallas de mantenimiento y búsqueda.Construimos esto sobre OpenACS.Puede obtener más información en www.openacs.org: busque "flexbase" o "dynfields" o busque aquí www.project-open.org/doc/intranet-dynfield/.Esto funcionó bastante bien: su principal desventaja es un efecto secundario de la principal ventaja, es decir,que la adición de campos podría ser realizada por personas que no sean DBA y, como resultado, el rendimiento podría verse fácilmente comprometido.

Answer 4

He hecho esto en el pasado usando una columna XML en la base de datos para almacenar los campos adicionales.Por lo general, solo tengo una gran bolsa de propiedades en la columna XML y luego uso XSD para imponer la validación al realizar actualizaciones o inserciones.Cuando recupero los datos, tengo reglas en XSL o el modelo de objetos que determinan si se muestra el elemento, qué formato adicional aplicar y, para formularios web, qué tipo de elemento de entrada usar según el tipo de datos en el nodo de propiedad.

Funciona muy bien si es necesario almacenar algunos datos de forma relacional y otros datos almacenados de forma extensible para evitar el efecto de tabla ancha con muchas filas nulas.

Si no necesita hacer cosas relacionales con los datos, como unir o pivotar con otras tablas en la base de datos, entonces un formulario XML simple e independiente también es una buena solución.

La mayoría de las bases de datos ahora tienen soporte XML de primera clase para este tipo de cosas.En SQL Server, por ejemplo, puede aplicar un esquema XSD a una columna de un tipo de datos XML directamente en la base de datos.En versiones recientes también se admite la indexación en esas columnas.