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

Question

En varios proyectos de aplicaciones web de los que he sido parte, el cliente solicita poder crear sus propios formularios. La pregunta que surge es cómo almacenar las definiciones de sus formularios y luego cómo almacenar los valores ingresados ??por el usuario en esos formularios personalizados.

Lo he visto hecho de dos maneras:

1. Suponiendo que el cliente solo define cuántos campos y qué etiquetas están asociadas con esos campos; Podemos llegar a una solución con cuatro tablas. FormDefinition , FormFieldDefinition , FormInstances , FormFieldValues ?? . El cliente realiza cambios en FormDefinition y FormFieldDefinition , y la aplicación web utiliza esa información para representar un formulario web HTML, en el que el visitante del sitio web (usuario final) enviará el formulario , en la que se crea una nueva fila en FormInstances y los valores se guardan en la tabla FormFieldValues ??.

     

   Las filas en FormDefinition definen el formulario, es decir, ID de definición de formulario = 2, formulario título = 'Formulario de registro de automóvil' . Las filas en FormFieldDefinition definen los campos de un formulario en FormDefinition , es decir, la definición del campo ID = 7, field label = 'Car Model', tipo de campo = 'varchar (50)' . Las 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, definición de campo = 7, value = 'Tiburon' .

   Desafortunadamente, significa que la columna de valor en FormFieldValues ?? debe ser un tipo de char del mayor tamaño posible que su cliente pueda especificar en un formulario web ... y cuando cambian las definiciones de formularios, administrando datos antiguos se vuelve dudoso. Pero las entradas de usuario son consultables (escribí una consulta rápida que enumera las entradas de usuario a las que se asigna un ID de formulario, que es similar a otra pregunta dinámica ).

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 almacenarlas como texto. La ventaja es que los formularios son legibles por humanos en la base de datos. La desventaja es que habrá más sobrecarga de la aplicación con el análisis de XML, y la base de datos se vuelve mucho menos consultable desde un punto de vista de SQL.

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

Answer 1

Lo que estás describiendo a menudo se llama " Entity-Attribute-Value, " 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 conduce a una serie de problemas complejos, como asegurarse de que cada instancia del formulario incluya el mismo conjunto de campos o de que los campos obligatorios se completen (el equivalente de NO NULL en una tabla convencional).

Usted preguntó cuál es la mejor manera de 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 del formulario es una fila en esa tabla. Si admite formularios con respuestas de valor múltiple (por ejemplo, casillas de verificación), también necesita tablas dependientes.

Esto puede parecer caro o difícil de escalar. Probablemente cierto. Por lo tanto, 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 el formulario de cada cliente, de modo que cada formulario recopilado pueda validarse.

editar: Si realmente necesita la flexibilidad de EAV en su aplicación, está bien, por lo general hay circunstancias que justifican romper las reglas. Solo tenga en cuenta el trabajo adicional que requiere, y planifíquelo en su programa de desarrollo y a medida que escala su servidor para manejar la carga. También vea otra mi respuesta sobre EAV en StackOverflow.

Answer 2

  

¿Cómo se llama este modelo de base de datos?

No estoy seguro de cómo llamarlo realmente, pero es el mismo proceso que se usa para generar encuestas dinámicamente. Si busca cualquier fuente para generar aplicaciones de encuestas, encontrará el mismo esquema de base de datos general y métodos similares.

También busque en 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 crea tablas y agrega columnas si es necesario. Depende de cuántos formularios se crean, pero las bases de datos pueden manejar fácilmente muchas tablas. Entonces, si un usuario desea agregar un formulario 'Formulario de registro de automóvil', agrega una tabla 'CarRegistrationForm'. Para cada campo que deseen en el formulario, puede permitirles elegir entre algunos tipos básicos como fecha, int y texto. Y cuando se elige el texto, tienen que ingresar una longitud máxima de una lista de selección, que le da información si el campo debe ser un varchar o un clob.

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

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

Answer 4

Probablemente quieras Modelo de relaciones entre entidades

De hecho, existen herramientas GUI para crear esquemas interactivamente a partir de dichos modelos.