Design de banco de dados para uma pesquisa [fechado]

Preciso criar uma pesquisa em que as respostas sejam armazenadas em um banco de dados. Só estou me perguntando qual seria a melhor maneira de implementar isso no banco de dados, especificamente as tabelas necessárias. A pesquisa contém diferentes tipos de perguntas. Por exemplo: campos de texto para comentários, perguntas de múltipla escolha e possivelmente perguntas que possam conter mais de uma resposta (por exemplo, marque todas as opções aplicáveis).

Eu vim com duas soluções possíveis:

1. Crie uma tabela gigante que contenha as respostas para cada envio de pesquisa. Cada coluna corresponderia a uma resposta da pesquisa. ie SurveyID, Answer1, Answer2, Answer3

   Não acho que seja a melhor maneira, pois há muitas perguntas nesta pesquisa e não parece muito flexível se a pesquisa for alterada.

2. A outra coisa que pensei foi criar uma tabela de perguntas e uma tabela de respostas. A tabela de perguntas conteria todas as perguntas da pesquisa. A tabela de respostas conteria respostas individuais da pesquisa, cada linha vinculada a uma pergunta.

   Um exemplo simples:

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID, UserID , QuestionID , Answer

   tblUser : UserID, UserName

   Meu problema com isso é que poderia haver toneladas de respostas que tornariam a tabela de respostas bastante grande. Não tenho certeza se isso é tão bom quando se trata de desempenho.

Eu apreciaria todas as idéias e sugestões.

Eu acho que seu modelo nº 2 está bom, mas você pode dar uma olhada no modelo mais complexo que armazena perguntas e respostas pré-elaboradas (respostas oferecidas) e permite que sejam reutilizadas em diferentes pesquisas.

- Uma pesquisa pode ter muitas perguntas; uma pergunta pode ser (re) usada em muitas pesquisas.
- Uma resposta (pré-fabricada) pode ser oferecida para muitas perguntas. Uma pergunta pode ter muitas respostas oferecidas. Uma pergunta pode ter respostas diferentes oferecidas em pesquisas diferentes. Uma resposta pode ser oferecida a diferentes perguntas em diferentes pesquisas. Há uma resposta "Outro" padrão, se uma pessoa escolher outra, sua resposta será registrada em Answer.OtherText.
- Uma pessoa pode participar de muitas pesquisas, uma pessoa pode responder a perguntas específicas em uma pesquisa apenas uma vez.

Meu design é mostrado abaixo.

O script de criação mais recente está em https://gist.github.com/durrantm/1e618164fd4acf91e372

O script e o arquivo mysql workbench.mwb também estão disponíveis em
https://github.com/durrantm/survey

Definitivamente, a opção 2, também acho que você pode ter uma supervisão no esquema atual, talvez queira outra tabela:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

Cada pergunta provavelmente terá um número definido de respostas que o usuário pode selecionar; as respostas reais serão rastreadas em outra tabela.

Os bancos de dados são projetados para armazenar muitos dados, e a maioria é dimensionada muito bem. Não há necessidade real de usar uma forma normal menor , simplesmente para economizar mais espaço.

Como regra geral, modificar o esquema com base em algo que um usuário pode alterar (como adicionar uma pergunta a uma pesquisa) deve ser considerado bastante fedorento. Há casos em que isso pode ser apropriado, principalmente ao lidar com grandes quantidades de dados, mas saiba no que você está se metendo antes de mergulhar. Ter apenas uma tabela de "respostas" para cada pesquisa significa que adicionar ou remover perguntas é potencialmente muito caro. e é muito difícil fazer análises de maneira independente de perguntas.

Acho que sua segunda abordagem é a melhor, mas se você tiver certeza de que terá muitas preocupações com a escala, uma coisa que funcionou para mim no passado é uma abordagem híbrida:

1. Crie tabelas de respostas detalhadas para armazenar respostas por pergunta, conforme descrito em 2. Esses dados geralmente não seriam consultados diretamente do seu aplicativo, mas seriam usados ​​para gerar dados de resumo para as tabelas de relatórios. Você provavelmente também desejaria implementar alguma forma de arquivamento ou exclusão para esses dados.
2. Crie também a tabela de respostas a partir de 1, se necessário. Isso pode ser usado sempre que os usuários quiserem ver uma tabela simples para obter resultados.
3. Para qualquer análise que precise ser feita para fins de relatório, programe tarefas para criar dados de resumo adicionais com base nos dados de 1.

Isso é absolutamente muito mais trabalho a ser implementado, por isso, eu realmente não recomendaria isso, a menos que você tenha certeza de que esta tabela vai se deparar com enormes preocupações de escala.

A segunda abordagem é a melhor.

Se você quiser normalizá-lo ainda mais, poderá criar uma tabela para tipos de perguntas

As coisas simples a fazer são:

• Coloque o banco de dados e faça logon em seu próprio disco, nem todos em C como padrão
• Crie o banco de dados tão grande quanto necessário, para que você não tenha pausas enquanto o banco de dados cresce

Tivemos tabelas de log na tabela do SQL Server com dezenas de milhões de linhas.

O número 2 parece bom.

Para uma tabela com apenas 4 colunas, não deve ser um problema, mesmo com alguns milhões de linhas. Claro que isso pode depender de qual banco de dados você está usando. Se é algo como o SQL Server, então não haveria problema.

Você provavelmente desejaria criar um índice no campo QuestionID, na tabela tblAnswer.

Obviamente, você precisa especificar qual banco de dados está usando, bem como os volumes estimados.

Parece bastante completo para uma pesquisa simples. Não se esqueça de adicionar uma tabela para 'valores abertos', onde um cliente pode dar sua opinião através de uma caixa de texto. Vincule essa tabela com uma chave estrangeira à sua resposta e coloque índices em todas as suas colunas relacionais para obter desempenho.

O número 2 está correto. Use o design correto até e a menos que você detecte um problema de desempenho. A maioria dos RDBMS não terá problemas com uma tabela estreita, mas muito longa.

Ter uma tabela de respostas grande, por si só, não é um problema. Desde que os índices e restrições estejam bem definidos, você deve estar bem. Seu segundo esquema parece bom para mim.

Dado o índice adequado, sua segunda solução é normalizada e boa para um sistema tradicional de banco de dados relacional.

Eu não sei o quão grande é enorme, mas deve conter, sem problemas, alguns milhões de respostas.

Você pode optar por armazenar o formulário inteiro como uma string JSON.

Não tenho certeza sobre sua exigência, mas essa abordagem funcionaria em algumas circunstâncias.