Modelagem para questionário

Depende do cenário a ser empregado, como vai ser executado:

1 - Questionários podem ser criados e editados?

2 - Perguntas podem ser criadas, editadas ou removidas do questionário?

3 - Mais de uma pessoa pode responder ao mesmo questionário?

Supondo que sim no básico dessas três questões, sem levar em conta de como deve funcionar o carregamento dos dados, como será o funcionamento do software.... De qualquer forma eu optaria por usar tabelas distintas para cada armazenamento.

Fica até mais simples gerenciar, evita confusão em manutenções se as tabelas apenas tem o que é necessário possuir, é a mesma lógica de um código orientado onde os métodos apenas fazem o que tem de fazer.

Veja como pensei na arquitetura:

DROP TABLE IF EXISTS `questionario`;
DROP TABLE IF EXISTS `pergunta`;
DROP TABLE IF EXISTS `resposta`;

CREATE TABLE `questionario` (
 `q_id` int(9) NOT NULL AUTO_INCREMENT,
 `q_title` varchar(100) NOT NULL DEFAULT '' COMMENT 'Titulo do questionario',
 `q_publicado` date COMMENT 'Data em que foi publicado',
 PRIMARY KEY (`q_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `pergunta` (
 `p_id` int(9) NOT NULL AUTO_INCREMENT,
 `p_pergunta` varchar(200) NOT NULL DEFAULT '' COMMENT 'Texto da pergunta',
 `p_questionario` int(9) NOT NULL DEFAULT '0' COMMENT 'A qual questionario pertence',
 PRIMARY KEY (`p_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `resposta` (
 `r_id` int(9) NOT NULL AUTO_INCREMENT,
 `r_resposta` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT 'Resposta da pergunta',
 `r_respondida` date COMMENT 'Data em que foi respondida',
 `r_pergunta` int(9) NOT NULL DEFAULT '0' COMMENT 'A qual pergunta pertence',
 `r_pessoa` int(9) NOT NULL DEFAULT '0' COMMENT 'Pessoa que respondeu',
 PRIMARY KEY (`r_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

	 

	Fazendo a(s) pergunta(s)

>

Citar

- Pessoa abre o questionário

- As perguntas serão buscadas pelo id do questionário através da coluna p_questionario

Perceba que assim as perguntas podem ser carregadas sem as respostas evitando assim registros de perguntas duplicados no banco de dados para cada resposta que foi inserida.

Imaginando assim não terei a mesma pergunta repetida em cada resposta para ela.

Vendo a(s) resposta(s) do questionário

>

Citar

- O mesmo procedimento anterior

- As respostas serão buscadas pelos resultados da coluna r_pergunta

- Se não existe é porque não foi respondida

Entretanto também pode-se armazenar a respostas se foi ou não respondida, exemplo se não houve dados para inserir na coluna r_resposta pode-se adicionar a base da tabela uma nova coluna para essa função

-- na tabela resposta
q_respondida enum('s', 'n') NOT NULL DEFAULT 'n' NULL COMMENT 's = foi respondida, n = nao foi respondida',

Particularmente não vejo necessidade de registro para sim ou não, uma vez como mencionei é que se não tem registro do id da pergunta nas respostas para tal é porque não respondeu.

Mantenha atenção na tabela de resposta, através dela você chega as perguntas, pelas perguntas ao formulário e vice-versa conforme for a necessidade.

E mesmo que não haja necessidade de múltiplas pessoas responder, essa arquitetura acredito ser mais coesa.... se não há resposta o formulário não foi respondido.

Por fim não se esqueça de um bom tratamento dos dados a serem inseridos na coluna r_resposta por ser um tipo text; códigos podem ser inseridos no banco de dados, códigos de quebra de estrutura ou executáveis ao serem carregados em uma instrução.

#EDIT#

>

Em 31/07/2025 at 11:08, FabianoSouza disse:

Eu acho estranho ter uma tabela auxiliar para guardar data de resposta do questionário, "status" do questionário (se foi respondido ou não) e etc.

Mas também acho estranho extrair essas informações da tabela que armazena as respostas, pois as informações se repetiriam (pensando num questionário cujas respostas são gravadas juntas, ao mesmo tempo).

Realmente para fins de agrupamento uma nova tabela seria necessária para registrar a data, porém pensando na ergonomia de dados possuir outra tabela nessa finalidade geraria muito mais armazenamento a longo prazo.

Então apenas registre uma vez a data de uma resposta, assim não precisa armazenar novamente a mesma coisa; essa servirá para determinar quando foi respondido.

- Se respondeu pergunta A registre a data, se respondeu pergunta B não precisa registrar a data novamente.

Pode até optar em usar um varchar ao invés de date, assim pode-se manter a coluna vazia para as demais resposta economizando no armazenamento.

Oá @Omar~!

Muito obrigado pela ajuda.

Sua resposta foi bastante clara e trouxe direcionamentos para eu resolver meu problema.

No meu caso, são questionários que poderão ser respondidos por várias pessoas.

Para responder, os usuários apenas selecionarão possíveis respostas já pré-definidas.

Minha estrutura está similar ao que você sugeriu (eu tenho uma tabela de perguntas, e outra de respostas).

Minha dúvida era justamente se eu deveria criar ou não a tabela "questionário". Para essa situação em particular, acredito que não precisarei criar essa tabela porque são perguntas "de sistema", ou seja, não serão criadas pelo usuário e nem pelo gestor do sistema (são questões baseadas em uma metodologia de análises comportamentais, então não mudam).

Mas agora entendo que para criar avaliações para outros contextos, como por exemplo para aferir conhecimentos, eu precisarei ter essa tabela "questionário".

Mais uma vez, muito obrigado pela grande ajuda.

Valew!

Sexy girls are waiting for live chat and discreet adult dating. Join now.

https://privateladyescorts.com

erotic profiles online