¿Cuál es la mejor implementación de formularios web modificables y creables por el cliente en una base de datos relacional?

Question

En varios proyectos de aplicaciones web de los que he formado parte, el cliente solicita poder crear sus propios formularios. Surge la pregunta sobre cómo almacenar sus definiciones de formulario y cómo almacenar los valores ingresados ​​por el usuario en esos formularios personalizados.

lo he visto hacer de dos formas:

1. Suponiendo que el cliente sólo define la forma en muchos campos, y qué etiquetas están asociados con esos campos; podemos llegar a una solución que involucra cuatro tablas. FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues. El cliente realiza cambios en FormDefinition y FormFieldDefinition, y la aplicación web utiliza esa información para generar un formulario web HTML, en el que el visitante del sitio web (usuario final) enviará el formulario, en el que se creará una nueva fila en FormInstances y los valores serán guardado en la tabla FormFieldValues.

   filas en FormDefinition define la forma, es decir form definition ID = 2, form title = 'Car Registration Form'. Filas en FormFieldDefinition define campos de un formulario en FormDefinition, es decir, field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'. Filas en FormInstance es una instancia de cada formulario completado por un usuario, es decir, definition id = 2, date_entered = '2008-09-24'. Y las filas en FormFieldValues son entradas del usuario, es decir, field definition = 7, value = 'Tiburon'.

   Desafortunadamente, esto significa la columna de valor en FormFieldValues debe ser un tipo char del mayor tamaño posible que su cliente podría especificar en un formulario web ... y cuando cambian las definiciones de formulario, la gestión de los datos de edad se convierte en dudoso. Pero las entradas de usuario son consultables (escribí un quick query que enumera las entradas de usuario con un ID de formulario, que es similar a another pivot question).

2. Una alternativa al uso de cuatro tablas sería serializar las definiciones de formulario y las entradas de formulario del usuario en XML (o YAML o algo similar) y almacenar eso como texto. Lo bueno es que los formularios son legibles por humanos en la base de datos. La desventaja es que habrá más sobrecarga de aplicaciones al analizar XML, y la base de datos se vuelve mucho menos consultable desde un punto de vista SQL.

Mi verdadera pregunta es, ¿cómo se llama este modelo de base de datos? (Así que puedo buscar en Google este problema.) Pero me gustaría conformarme con una respuesta a: ¿cuál es la mejor implementación o hay mejores implementaciones (o tan buenas) por ahí?

Answer 1

Lo que está describiendo a menudo se llama "Entidad-Valor-Atributo" y, a veces se describe como "mezcla de datos y metadatos". Es decir, los nombres de los atributos (campos) se almacenan como cadenas (datos).

Esto lleva a un montón de problemas complejos como asegurarse de que cada instancia de formulario incluya el mismo conjunto de campos, o asegurarse de que se completen los campos obligatorios (el equivalente a NOT NULL en una tabla convencional).

Ha preguntado cómo hacer esto con una base de datos relacional. En una base de datos relacional, debe usar metadatos para metadatos. En este caso, significa crear nuevas tablas para cada formulario y usar columnas para los campos de formulario. Entonces, la definición de su formulario es simplemente los metadatos de la tabla, y una instancia de formulario es una fila en esa tabla. Si admite formularios con respuestas multivaluadas (por ejemplo, casillas de verificación), también necesita tablas dependientes.

Esto puede parecer costoso o difícil de escalar. Probablemente cierto. Entonces, una base de datos relacional podría no ser la mejor herramienta para este trabajo. Usted mencionó la posibilidad de XML o YAML; básicamente, algún tipo de formato de archivo estructurado que puede definir ad hoc. Debe definir una DTD para cada formulario de cliente, de modo que cada formulario recopilado pueda validarse.

edición: Si realmente necesita la flexibilidad de EAV en su aplicación, está bien, generalmente hay circunstancias que justifican el incumplimiento de las reglas. Solo tenga en cuenta el trabajo adicional que se necesita y planee en su programa de desarrollo y en la escala del servidor para manejar la carga. También vea otro answer of mine about EAV en StackOverflow.

Answer 2

¿con qué se hace referencia?

No estoy seguro de cómo llamarlo en realidad, pero es el mismo proceso que se utiliza en la generación dinámica de encuestas. Si busca cualquier fuente para generar encuestas, encontrará el mismo esquema general de base de datos y métodos similares.

Consulte también los sitios de creación de formularios, como http://wufoo.com/ o http://frevvo.com/ para obtener ideas de UI (si lo está haciendo en la web).

Answer 3

Hay una tercera opción, donde puede crear tablas y agregar columnas si es necesario. Depende de cuántos formularios se creen, pero las bases de datos pueden manejar fácilmente muchas tablas. Por lo tanto, si un usuario desea agregar un formulario 'Formulario de registro de automóvil', debe agregar una tabla 'CarRegistrationForm'. Para cada campo que desean en el formulario, puede permitirles elegir entre algunos tipos básicos como fecha, int y texto. Y cuando se elige texto, tienen que ingresar una longitud máxima desde una lista de selección, que le proporciona información si el campo debe ser varchar o clob.

Esto funciona en SQL Server, donde puede agregar y soltar columnas fácilmente. Para DB2 puede ser un problema, porque la columna desplegable no está implementada. Para mysql no estoy seguro.

Aún necesita registrar sus formularios y los campos en dos tablas separadas.

Answer 4

es probable que desee Entity-Relationship Model

De hecho, existen herramientas de GUI para crear el esquema de forma interactiva a partir de tales modelos.