Concepção da base de dados para um inquérito [encerrado]
- Criar um gigante quadro que contém as respostas para cada inquérito submissao. Cada coluna iria corresponde a uma resposta do inquerito. ou seja, Levantador, Answer1, Answer2, Answer3 Acho que esta não é a melhor maneira. uma vez que há muitas perguntas nesta pesquisa e não parece muito flexível se a pesquisa for para mudar.
-
A outra coisa em que pensei foi ...
criar uma tabela de perguntas e Respostas
tabela. O quadro de perguntas
conter todas as perguntas para a
inquerito. Resposta a tabela conteria
respostas individuais do inquérito,
cada fila ligada a uma pergunta.
um exemplo simples:
TblSurvey : SurveyID
Tblqu Question: QuestionID, SurveyID, QuestionType, Question
TblAnswer : AnswerID, UserID, Pergunta , Resposta
TblUser : Utilizador, Utilizador
O meu problema com isto é que ... podem ser toneladas de respostas que faça a resposta a mesa é enorme. Não sei se é assim tão bom quando ... vem ao espectáculo.
11 answers
Eu acho que o seu modelo # 2 está bem, no entanto você pode dar uma olhada no modelo mais complexo que armazena perguntas e respostas pré-feitas (respostas oferecidas) e permite que elas sejam reutilizadas em diferentes pesquisas.
- uma pesquisa pode ter muitas perguntas; uma pergunta pode ser (re)usada em muitas pesquisas.
- uma resposta (pré-feita) pode ser oferecida para muitas perguntas. Uma pergunta pode ter muitas respostas. Uma pergunta pode ter respostas diferentes em diferentes pesquisas. Uma resposta pode ser oferecidos a diferentes perguntas em diferentes pesquisas. Há uma resposta padrão "Outra", se uma pessoa escolhe outra, sua resposta é gravada em resposta.Outro texto.
Uma pessoa pode participar em muitos inquéritos, uma pessoa pode responder a uma pergunta específica num inquérito apenas uma vez.
O meu desenho é mostrado abaixo.
O mais recente script create é em https://gist.github.com/durrantm/1e618164fd4acf91e372
O guião e a bancada de trabalho do mysql.o ficheiro mwb também está disponível em:https://github.com/durrantm/survey
Definitivamente Opção #2, também acho que você pode ter um lapso no esquema atual, você pode querer 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 das quais o usuário pode selecionar, então as respostas reais serão rastreadas em outra tabela.
As bases de dados são concebidas para armazenar muitos dados, e a maior parte escala muito bem. Não há necessidade real de usar uma forma normal menor apenas para guardar no espaço.
- crie tabelas de resposta detalhadas para armazenar as respostas por Pergunta Como você descreveu em 2. Estes dados geralmente não seriam diretamente questionados a partir de sua aplicação, mas seriam usados para gerar dados resumidos para tabelas de relatórios. Você provavelmente também gostaria de implementar alguma forma de arquivamento ou a eliminar estes dados.
- também crie a tabela de respostas a partir de 1 Se necessário. Isto pode ser usado sempre que os usuários querem ver uma tabela simples para resultados.
- para qualquer análise que precise de ser feita para fins de comunicação, programe postos de trabalho para criar dados resumidos adicionais com base nos dados de 1.
Se quiser normalizá-lo ainda mais, poderá criar uma tabela para os tipos de perguntas
As coisas simples a fazer são:
- Coloque a base de dados e faça login no seu próprio disco, nem tudo em C por omissão
- Crie a base de dados tão grande quanto necessário para que não tenha pausas enquanto a base de dados cresce
Temos tabelas de log na tabela do servidor SQL com 10 de milhões de linhas.
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 do banco de dados que você está usando. Se for algo como o servidor SQL então não será problema.
Você provavelmente gostaria de criar um índice no campo QuestionID, na tabela tblAnswer.
É claro que precisa de especificar qual a base de dados que está a utilizar, bem como os volumes estimados.
O número 2 está correcto. Use o design correto até e a menos que você detecte um problema de desempenho. A maioria das RDBMS não terá um problema com uma mesa estreita, mas muito longa.
Dado o índice adequado, a sua segunda solução está normalizada e é boa para um sistema de base de dados relacional tradicional.
Não sei se é enorme, mas deve aguentar sem problemas alguns milhões de respostas.Você pode optar por armazenar o formulário inteiro como uma cadeia JSON.
Não tenho a certeza quanto às suas exigências, mas esta abordagem funcionaria em algumas circunstâncias.