Modelo de dados para um formulário web extensível

Question

Suponha que eu tenha um formulário que contenha três campos 10:campo1..campo10.Eu armazeno os dados do formulário em uma ou mais tabelas do banco de dados, provavelmente usando 10 colunas do banco de dados.

Agora, suponha que alguns meses depois eu queira adicionar mais 3 campos.E no futuro poderei adicionar/excluir campos deste formulário com base nas alterações de requisitos.Se eu tiver uma coluna de banco de dados por campo de formulário, terei que fazer as alterações correspondentes no banco de dados cada vez que alterar o formulário.Isso parece uma dor de cabeça de manutenção.Deve haver uma maneira mais sofisticada.

Então, minha pergunta é: como faço para projetar um modelo de dados que esteja fracamente acoplado à minha UI?Um caso de uso concreto é um sistema CRM extensível/personalizável pelos usuários.

Answer 1

A menos que você tenha um bom motivo para fazer isso, geralmente é uma má ideia.Isso torna muito difícil otimizar e dimensionar o banco de dados.

Se você realmente precisa fazer isso, então a sugestão de Travis é boa para mesas pequenas, mas não vai escalar muito bem.

Answer 2

Você poderia abstrair os campos para uma tabela separada para que eles fossem muitos para muitos na tabela Form:

Forma

EU IA
Nome
etc.

Campo

EU IA
Rótulo
Valor

FormField

ID do formulário
ID do campo

Answer 3

Minha equipe encontrou uma solução para isso quando trabalhei na Quest Computing no AIMS (www.totalaims.com).Em resumo adicionamos telas de manutenção que permitiam ao administrador adicionar metadados e também como resultado adicionar campos ao banco de dados em determinadas tabelas.Os campos também foram adicionados às suas próprias telas de manutenção e pesquisa automaticamente.Construímos isso em cima do OpenACS.Você pode descobrir mais em www.openacs.org - pesquise "flexbase" ou "dynfields" ou veja aqui www.project-open.org/doc/intranet-dynfield/ .Isso funcionou muito bem - a principal desvantagem era um efeito colateral da principal vantagem, ou seja,essa adição de campos poderia ser feita por não-DBAs e, como resultado, o desempenho poderia ser facilmente comprometido.

Answer 4

Já fiz isso no passado usando uma coluna XML no banco de dados para armazenar os campos extras.Geralmente, tenho apenas um grande pacote de propriedades na coluna XML e, em seguida, uso o XSD para impor a validação ao fazer atualizações ou inserções.Quando estou recuperando os dados, tenho regras em XSL ou no modelo de objeto que determinam se o elemento é exibido, qual formatação adicional aplicar e, para formulários da Web, que tipo de elemento de entrada usar com base no tipo de dados no nó de propriedade.

Funciona muito bem se houver necessidade de armazenar alguns dados de forma relacional e outros dados armazenados de forma extensível para evitar o efeito de tabela ampla com muitos efeitos de linhas nulas.

Se você não precisa fazer coisas relacionais com os dados, como unir ou dinamizar outras tabelas no banco de dados, um formulário XML simples e independente também é uma boa solução.

A maioria dos bancos de dados agora tem suporte XML de primeira classe para esse tipo de coisa.No SQL Server, por exemplo, você pode aplicar um esquema XSD a uma coluna de um tipo de dados XML diretamente no banco de dados.Nas versões recentes também há suporte para indexação nessas colunas.