설문 조사를위한 데이터베이스 설계

설문 조사를위한 데이터베이스 설계

---

답변이 데이터베이스에 저장된 설문 조사를 작성해야합니다. 데이터베이스, 특히 필요한 테이블에서이를 구현하는 가장 좋은 방법이 무엇인지 궁금합니다. 설문 조사에는 여러 유형의 질문이 포함되어 있습니다. 예를 들면 다음과 같습니다. 설명 텍스트 필드, 객관식 질문 및 둘 이상의 답변을 포함 할 수있는 질문 (예 : 해당되는 모든 항목을 확인).

두 가지 가능한 솔루션을 생각해 냈습니다.

1. 각 설문 제출에 대한 답변이 포함 된 거대한 테이블을 만듭니다. 각 열은 설문 조사의 답변에 해당합니다. 즉, SurveyID, Answer1, Answer2, Answer3

   이 설문 조사에 많은 질문이 있기 때문에 이것이 최선의 방법이라고 생각하지 않으며 설문 조사가 변경되어야하는 경우 매우 유연하게 보이지 않습니다.

2. 내가 생각한 다른 것은 질문 테이블과 답변 테이블을 만드는 것이 었습니다. 질문 테이블에는 설문에 대한 모든 질문이 포함됩니다. 답변 표에는 설문 조사의 개별 답변이 포함되며 각 행은 질문에 연결됩니다.

   간단한 예 :

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, 질문

   tblAnswer : AnswerID , UserID , QuestionID , 답변

   tblUser : 사용자 ID, 사용자 이름

   이것에 대한 나의 문제는 답변 테이블을 꽤 크게 만들 수있는 많은 답변이있을 수 있다는 것입니다. 성능면에서 그렇게 큰지 잘 모르겠습니다.

나는 어떤 아이디어 나 제안에 감사드립니다.

---

모델 2 번은 괜찮다고 생각하지만 질문과 사전 답변 (제공된 답변)을 저장하고 다른 설문 조사에서 재사용 할 수있는 더 복잡한 모델을 살펴볼 수 있습니다.

-하나의 설문 조사에는 많은 질문이있을 수 있습니다. 하나의 질문은 많은 설문 조사에서 (재) 사용될 수 있습니다.
-많은 질문에 대해 하나의 (사전 제작 된) 답변을 제공 할 수 있습니다. 하나의 질문에는 많은 답변이 제공 될 수 있습니다. 질문은 다른 설문 조사에서 다른 답변을 제공 할 수 있습니다. 설문 조사마다 다른 질문에 대한 답변을 제공 할 수 있습니다. 기본 "기타"답변이 있습니다. 사람이 다른 것을 선택하면 답변이 Answer.OtherText에 기록됩니다.
-한 사람이 여러 설문 조사에 참여할 수 있으며 한 사람이 설문 조사의 특정 질문에 한 번만 답변 할 수 있습니다.

---

내 디자인은 아래와 같습니다.

최신 작성 스크립트는 https://gist.github.com/durrantm/1e618164fd4acf91e372에 있습니다.

스크립트 및 mysql workbench.mwb 파일은 https://github.com/durrantm/survey 에서 제공됩니다.

---

확실히 옵션 # 2, 또한 현재 스키마를 감독 할 수 있다고 생각하면 다른 테이블을 원할 수 있습니다.

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

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

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

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

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

각 질문에는 아마도 사용자가 선택할 수있는 정해진 수의 답변이있을 것이며, 실제 답변은 다른 표에서 추적 될 것입니다.

데이터베이스는 많은 데이터를 저장하도록 설계되었으며 대부분 확장 성이 뛰어납니다. 더 이상 공간을 절약하기 위해 더 적은 일반 양식을 사용할 필요가 없습니다.

---

As a general rule, modifying schema based on something that a user could change (such as adding a question to a survey) should be considered fairly smelly. There's cases where it can be appropriate, particularly when dealing with large amounts of data, but know what you're getting into before you dive in. Having just a "responses" table for each survey means that adding or removing questions is potentially very costly, and it's very difficult to do analytics in a question-agnostic way.

I think your second approach is best, but if you're certain you're going to have a lot of scale concerns, one thing that has worked for me in the past is a hybrid approach:

1. Create detailed response tables to store per-question responses as you've described in 2. This data would generally not be directly queried from your application, but would be used for generating summary data for reporting tables. You'd probably also want to implement some form of archiving or expunging for this data.
2. Also create the responses table from 1 if necessary. This can be used whenever users want to see a simple table for results.
3. For any analytics that need to be done for reporting purposes, schedule jobs to create additional summary data based on the data from 1.

This is absolutely a lot more work to implement, so I really wouldn't advise this unless you know for certain that this table is going to run into massive scale concerns.

---

The second approach is best.

If you want to normalize it further you could create a table for question types

The simple things to do are:

• Place the database and log on their own disk, not all on C as default
• Create the database as large as needed so you do not have pauses while the database grows

We have had log tables in SQL Server Table with 10's of millions rows.

---

No 2 looks fine.

For a table with only 4 columns it shouldn't be a problem, even with a good few million rows. Of course this can depend on what database you are using. If its something like SQL Server then it would be no problem.

You'd probably want to create an index on the QuestionID field, on the tblAnswer table.

Of course, you need to specify what Database you are using as well as estimated volumes.

---

Looks pretty complete for a smiple survey. Don't forget to add a table for 'open values', where a customer can provide his opinion via a textbox. Link that table with a foreign key to your answer and place indexes on all your relational columns for performance.

---

Number 2 is correct. Use the correct design until and unless you detect a performance problem. Most RDBMS will not have a problem with a narrow but very long table.

---

Having a large Answer table, in and of itself, is not a problem. As long as the indexes and constraints are well defined you should be fine. Your second schema looks good to me.

---

Given the proper index your second solution is normalized and good for a traditional relational database system.

I don't know how huge is huge but it should hold without problem a couple million answers.

---

전체 양식을 JSON 문자열로 저장하도록 선택할 수 있습니다.

요구 사항에 대해 잘 모르지만이 방법은 일부 상황에서 작동합니다.

참고 URL : https://stackoverflow.com/questions/1764435/database-design-for-a-survey