Asesoramiento sobre esquemas de base de datos para almacenar campos de formulario y valores de campo

Question

Se me ha encomendado la creación de una aplicación que permita a los usuarios ingresar datos en un formulario web que se guardará y luego se usará para completar campos de formulario en PDF.

Tengo problemas para pensar en una buena forma de almacenar los valores de campo en una base de datos ya que los formularios serán dinámicos (basados ​​en campos de pdf).

En la aplicación en sí pasaré los datos en una tabla hash (fieldname, fieldvalue) pero no sé la mejor manera de convertir los valores de hash a db.

Estoy utilizando MS SQL Server 2000 y asp.net webforms. ¿Alguien ha trabajado en algo similar?

Answer 1

¿Ha considerado usar una base de datos de documentos aquí? Este es el tipo de problema que resuelven mucho mejor que las soluciones RDBMS tradicionales. Personalmente, soy un gran fan de RavenDb. Otra opción bastante decente es CouchDb. Evitaría MongoDb porque realmente no es un lugar seguro para los datos en su implementación actual.

Incluso si no puede usar una base de datos documental, puede hacer que SQL finja ser uno configurando sus tablas para tener algunos metadatos en columnas tradicionales con un campo de carga que sea serializado XML o json. Esto te permitirá buscar metadatos mientras te mantienes fuera de EAV-land. EAV-land es un lugar horrible para estar.

ACTUALIZACIÓN

no estoy seguro de si existe una buena guía, pero el concepto es bastante simple. La idea básica es dividir las partes que desea consultar en columnas "normales" en una tabla, esto le permite consultar de manera estándar. Cuando encuentre los registros que desea, puede tomar el CLOB y deserializarlo según corresponda. En su caso, tendría una mesa que parecía algo así como:

SurveyAnswers 
    Id INT IDENTITY 
    FormId INT 
    SubmittedBy VARCHAR(255) 
    SubmittedAt DATETIME 
    FormData TEXT 

Unos protips:
a) utilizar una rutina de serialización basada en texto. Te da la oportunidad de luchar para corregir los errores de datos y realmente ayuda a la depuración.
b) Para SQL 2000, es posible que desee considerar romper el CLOB (campo TEXTO que contiene los datos de su carga útil) en una tabla separada. Ha pasado mucho tiempo desde que utilicé SQL 2000, pero mi recuerdo es que el uso de columnas TEXT le hizo mal a las tablas.

Answer 2

me gustaría sugerir que refleja la misma estructura:

Form 
----- 
form_id 
User 
created 

FormField 
------- 
formField_id 
form_id 
name 
value 

Answer 3

La solución para lo que estás describiendo se llama Entity Attribute Value (EAV) y este modelo puede ser un dolor real de tratar. Por lo tanto, debe limitar tanto como sea posible su uso de esto.

Por ejemplo, hay campos que casi siempre están en los formularios (nombre, apellido, correo electrónico, etc.), luego debe ponerlos en una tabla como campos.

La razón de esto es porque si no lo hace alguien tarde o temprano se va a dar cuenta de que tienen estos nombres y mensajes de correo electrónico y le pedirá que para construir esta consulta

 SELECT 
     Fname.value fname, 
     LName.Value lname, 
     email.Value email, 
     .... 
    FROM 
     form f 
     INNER JOIN formFields fname 
     ON f.FormId = ff.FormID 
      and AttributeName = 'fname'  
     INNER JOIN formFields lname 
     ON f.FormId = ff.FormID 
      and AttributeName = 'lname' 
     INNER JOIN formFields email 
     ON f.FormId = ff.FormID 
      and AttributeName = 'email' 
     .... 

cuando se podría haber escrito este

SELECT 
     common.fname, 
     common.lname, 
     common.email, 
     .... 
    FROM 
     form f 
     INNER JOIN common c 
     on f.FormId = c.FormId 

también bajarse de SQL 2000, tan pronto como sea posible, ya que vamos a perder realmente la cláusula UNPIVOT

también es p robablemente no es una mala idea mirar el anterior SO EAV questions para darle una idea de los problemas que la gente ha encontrado en el pasado