qual é a melhor implementação de creatable cliente e formulários web modificáveis ??em um banco de dados relacional?

Question

Em vários projetos de aplicativos web Estive uma parte, o cliente pede para ser capaz de criar suas próprias formas. Surge a pergunta sobre como armazenar suas definições de formulário e, em seguida, como armazenar valores introduzidos usuário para esses formulários personalizados.

Eu já vi isso feito de duas maneiras:

1. Assumindo que o cliente só define como muitos campos, e que as etiquetas são associadas a essas áreas; podemos chegar a uma solução que envolva quatro mesas. FormDefinition , FormFieldDefinition , FormInstances , FormFieldValues . O cliente faz alterações para FormDefinition e FormFieldDefinition, eo aplicativo web usa essas informações para tornar um formulário web HTML, em que o visitante do site (usuário final) irá enviar o formulário, no qual é criada uma nova linha na FormInstances e os valores são salvos na tabela de FormFieldValues.

   linhas em FormDefinition define a forma, isto é form definition ID = 2, form title = 'Car Registration Form'. Linhas em FormFieldDefinition Define campos de um formulário em FormDefinition, ou seja field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'. Fileiras em FormInstance é um exemplo de cada formulário preenchido por um utilizador, isto é definition id = 2, date_entered = '2008-09-24'. E linhas em FormFieldValues são entradas pelo usuário, ou seja, field definition = 7, value = 'Tiburon'.

   Infelizmente, isso significa que a coluna de valor em FormFieldValues deve ser um tipo char do maior tamanho possível que seu cliente pode especificar um formulário web ... e quando definições de formulário mudar, gerenciamento de dados de idade torna-se duvidoso. Mas as entradas de usuário são queryable (i escreveu um rápida consulta que as entradas listas de usuários dado um ID de formulário, que é semelhante ao outra questão pivô ).

2. Uma alternativa para utilizar quatro mesas seria serializar as definições de formulário e entradas de formulário do usuário em XML (ou YAML ou algo similar) e loja que como texto. A vantagem é que as formas são legível no banco de dados. A desvantagem é que haverá mais sobrecarga aplicação com análise de XML e banco de dados torna-se muito menos queryable do ponto de vista SQL.

A minha pergunta real é, o que é este modelo de banco de dados chamado? (Então eu posso google este problema.) Mas eu gostaria de resolver em uma resposta a: qual é a melhor implementação ou há melhor (ou tão bom) implementações lá fora

Answer 1

O que você está descrevendo é muitas vezes chamado de "Entidade-Atributo-Valor", e às vezes descrito como "mistura dados e metadados." Ou seja, os nomes de atributos (campos) são armazenados como strings (dados).

Isto leva a um monte de problemas complexos como certificando-se de cada instância formulário inclui o mesmo conjunto de campos, ou fazendo campos certeza obrigatórios são preenchidos (o equivalente a NOT NULL em uma mesa convencional).

Você pediu a melhor forma de fazer isso com um banco de dados relacional. Em um banco de dados relacional, você deve usar metadados para metadados. Neste caso, isto significa a criação de novos mesa (s) para cada formulário, e colunas de uso para os campos de formulário. Portanto, sua definição do formulário é simplesmente os metadados da tabela, e uma instância de formulário é uma linha na tabela. Se você apoiar formulários com respostas múltiplos valores (por exemplo caixas de seleção), você precisa de tabelas dependentes também.

Isto pode parecer caro ou difícil de escala. Provavelmente é verdade. Assim, um banco de dados relacional pode não ser a melhor ferramenta para este trabalho. Você mencionou a possibilidade de XML ou YAML; basicamente algum tipo de formato de arquivo estruturado que pode definir ad hoc. Você deve definir um DTD para o formulário de cada cliente, de modo que cada formulário coletado pode ser validado.

Editar: Se você realmente precisa da flexibilidade de EAV em sua aplicação, tudo bem, geralmente há circunstâncias que justificam quebrar as regras. Basta estar consciente do trabalho extra que leva, e plano para ele em sua agenda de desenvolvimento e como você dimensionar seu servidor para lidar com a carga. ver também outra resposta meu sobre EAV em StackOverflow.

Answer 2

O que é este modelo de banco de dados chamado?

Não sei o que realmente chamá-lo, mas é o mesmo processo usado em pesquisas que geram dinamicamente. Se você olhar para qualquer fonte de geração de aplicações de pesquisa você vai encontrar o mesmo esquema de banco de dados geral, bem como métodos semelhantes.

Também olhar para sites de construtor de formulários, como http://wufoo.com/ ou http://frevvo.com/ para ideias de interface do usuário (se você está fazendo isso com base na web).

Answer 3

Há uma terceira opção, onde você cria tabelas e colunas adicionar se necessário. Depende de como muitas formas são criadas, mas os bancos de dados pode lidar facilmente com um monte de tabelas. Portanto, se um usuário quer adicionar um 'Formulário de Registro Car' forma, você adiciona uma tabela 'CarRegistrationForm'. Para cada campo que eles querem no formulário, você pode deixá-los escolher entre alguns tipos básicos como data, int e texto. E quando o texto é escolhida, eles têm que entrar um comprimento máximo de uma lista de seleção, o que lhe dá informações se o campo deve ser um varchar ou um clob.

Isso funciona em SQL Server, onde você pode facilmente adicionar e colunas gota. Para o DB2 pode ser um problema, porque a coluna queda não está implementada. Para mysql eu não tenho certeza.

Você ainda precisa registrar seus formulários e os campos sobre ele em duas mesas separadas.

Answer 4

Você provavelmente quer Entidade-Relacionamento Modelo

De fato, há ferramentas GUI para criar o esquema de forma interativa a partir de tais modelos.