Thiết kế cơ sở dữ liệu cho một cuộc khảo sát [đóng]

Tôi cần tạo một khảo sát trong đó các câu trả lời được lưu trữ trong cơ sở dữ liệu. Tôi chỉ tự hỏi điều gì sẽ là cách tốt nhất để thực hiện điều này trong cơ sở dữ liệu, cụ thể là các bảng cần thiết. Khảo sát chứa các loại câu hỏi khác nhau. Ví dụ: các trường văn bản cho ý kiến, câu hỏi trắc nghiệm và có thể là các câu hỏi có thể chứa nhiều hơn một câu trả lời (nghĩa là kiểm tra tất cả những gì áp dụng).

Tôi đã đưa ra hai giải pháp khả thi:

1. Tạo một bảng khổng lồ chứa các câu trả lời cho mỗi lần gửi khảo sát. Mỗi cột sẽ tương ứng với một câu trả lời từ khảo sát. tức là SurveyID, Trả lời1, Trả lời2, Trả lời3

   Tôi không nghĩ rằng đây là cách tốt nhất vì có rất nhiều câu hỏi trong khảo sát này và dường như không linh hoạt nếu khảo sát thay đổi.

2. Một điều khác tôi nghĩ là tạo ra một bảng câu hỏi và bảng câu trả lời. Bảng câu hỏi sẽ chứa tất cả các câu hỏi cho khảo sát. Bảng câu trả lời sẽ chứa các câu trả lời riêng từ khảo sát, mỗi hàng được liên kết với một câu hỏi.

   Một ví dụ đơn giản:

   tblSurvey : SurveyID

   tblQuestion : Câu hỏi, Khảo sát , Loại câu hỏi, Câu hỏi

   tblAnswer : Trả lời , UserID , Câu hỏi , Trả lời

   tblUser : UserID, Tên người dùng

   Vấn đề của tôi với điều này là có thể có hàng tấn câu trả lời sẽ làm cho bảng Trả lời khá lớn. Tôi không chắc điều đó thật tuyệt vời khi nói đến hiệu suất.

Tôi đánh giá cao bất kỳ ý tưởng và đề xuất.

Tôi nghĩ rằng mô hình số 2 của bạn vẫn ổn, tuy nhiên bạn có thể xem mô hình phức tạp hơn lưu trữ các câu hỏi và câu trả lời được làm sẵn (câu trả lời được cung cấp) và cho phép chúng được sử dụng lại trong các khảo sát khác nhau.

- Một khảo sát có thể có nhiều câu hỏi; một câu hỏi có thể được (tái) sử dụng trong nhiều khảo sát.
- Một câu trả lời (làm sẵn) có thể được cung cấp cho nhiều câu hỏi. Một câu hỏi có thể có nhiều câu trả lời được đưa ra. Một câu hỏi có thể có câu trả lời khác nhau được đưa ra trong các cuộc khảo sát khác nhau. Một câu trả lời có thể được cung cấp cho các câu hỏi khác nhau trong các cuộc khảo sát khác nhau. Có một câu trả lời "Khác" mặc định, nếu một người chọn người khác, câu trả lời của cô ấy được ghi lại vào Trả lời. Khác.
- Một người có thể tham gia nhiều cuộc khảo sát, một người có thể trả lời câu hỏi cụ thể trong một cuộc khảo sát chỉ một lần.

Thiết kế của tôi được hiển thị dưới đây.

Tập lệnh tạo mới nhất có tại https://gist.github.com/durrantm/1e618164fd4acf91e372

Tập lệnh và tệp mysql workbench.mwb cũng có sẵn tại
https://github.com/durrantm/survey

Chắc chắn tùy chọn # 2, tôi cũng nghĩ rằng bạn có thể có một sự giám sát trong lược đồ hiện tại, bạn có thể muốn một bảng khác:

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

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

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

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

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

Mỗi câu hỏi sẽ có một số câu trả lời mà người dùng có thể chọn, sau đó các câu trả lời thực tế sẽ được theo dõi trong một bảng khác.

Cơ sở dữ liệu được thiết kế để lưu trữ rất nhiều dữ liệu và hầu hết quy mô rất tốt. Không có nhu cầu thực sự để sử dụng một hình thức bình thường ít hơn chỉ đơn giản là để tiết kiệm không gian nữa.

Theo nguyên tắc chung, sửa đổi lược đồ dựa trên thứ gì đó mà người dùng có thể thay đổi (chẳng hạn như thêm câu hỏi vào khảo sát) nên được coi là khá nặng mùi. Có những trường hợp có thể phù hợp, đặc biệt là khi xử lý một lượng lớn dữ liệu, nhưng hãy biết những gì bạn đang tham gia trước khi lặn. Chỉ cần một bảng "trả lời" cho mỗi khảo sát có nghĩa là thêm hoặc xóa câu hỏi có khả năng rất tốn kém và rất khó để phân tích theo cách không thể biết.

Tôi nghĩ cách tiếp cận thứ hai của bạn là tốt nhất, nhưng nếu bạn chắc chắn bạn sẽ có nhiều mối quan tâm về quy mô, một điều có hiệu quả với tôi trong quá khứ là cách tiếp cận hỗn hợp:

1. Tạo các bảng trả lời chi tiết để lưu trữ các câu trả lời cho mỗi câu hỏi như bạn đã mô tả trong 2. Dữ liệu này thường không được truy vấn trực tiếp từ ứng dụng của bạn, nhưng sẽ được sử dụng để tạo dữ liệu tóm tắt cho các bảng báo cáo. Bạn cũng có thể muốn thực hiện một số hình thức lưu trữ hoặc hết hạn cho dữ liệu này.
2. Đồng thời tạo bảng trả lời từ 1 nếu cần thiết. Điều này có thể được sử dụng bất cứ khi nào người dùng muốn xem một bảng đơn giản cho kết quả.
3. Đối với bất kỳ phân tích nào cần được thực hiện cho mục đích báo cáo, hãy lên lịch công việc để tạo dữ liệu tóm tắt bổ sung dựa trên dữ liệu từ 1.

Đây thực sự là rất nhiều công việc để thực hiện, vì vậy tôi thực sự sẽ không khuyên điều này trừ khi bạn biết chắc chắn rằng bảng này sẽ gặp phải những lo ngại quy mô lớn.

Cách tiếp cận thứ hai là tốt nhất.

Nếu bạn muốn bình thường hóa hơn nữa, bạn có thể tạo một bảng cho các loại câu hỏi

Những điều đơn giản để làm là:

• Đặt cơ sở dữ liệu và đăng nhập vào đĩa riêng của họ, không phải tất cả trên C là mặc định
• Tạo cơ sở dữ liệu lớn đến mức cần thiết để bạn không bị tạm dừng trong khi cơ sở dữ liệu phát triển

Chúng tôi đã có các bảng nhật ký trong Bảng SQL Server với 10 triệu hàng.

Số 2 có vẻ ổn.

Đối với một bảng chỉ có 4 cột thì đó không phải là vấn đề, ngay cả với một vài triệu hàng tốt. Tất nhiên điều này có thể phụ thuộc vào cơ sở dữ liệu bạn đang sử dụng. Nếu nó giống như SQL Server thì sẽ không có vấn đề gì.

Bạn có thể muốn tạo một chỉ mục trên trường Câu hỏi, trên bảng tblAnswer.

Tất nhiên, bạn cần chỉ định Cơ sở dữ liệu nào bạn đang sử dụng cũng như khối lượng ước tính.

Có vẻ khá đầy đủ cho một cuộc khảo sát smipl. Đừng quên thêm bảng cho 'giá trị mở', nơi khách hàng có thể đưa ra ý kiến ​​của mình thông qua hộp văn bản. Liên kết bảng đó với khóa ngoại với câu trả lời của bạn và đặt các chỉ mục trên tất cả các cột quan hệ của bạn để thực hiện.

Số 2 đúng. Sử dụng thiết kế chính xác cho đến khi và trừ khi bạn phát hiện ra vấn đề về hiệu suất. Hầu hết RDBMS sẽ không gặp vấn đề với bảng hẹp nhưng rất dài.

Có một bảng Trả lời lớn, trong và của chính nó, không phải là một vấn đề. Miễn là các chỉ số và các ràng buộc được xác định rõ, bạn sẽ ổn. Lược đồ thứ hai của bạn có vẻ tốt với tôi.

Với chỉ số thích hợp, giải pháp thứ hai của bạn được chuẩn hóa và tốt cho hệ thống cơ sở dữ liệu quan hệ truyền thống.

Tôi không biết làm thế nào lớn là rất lớn nhưng nó sẽ giữ mà không có vấn đề một vài triệu câu trả lời.

Bạn có thể chọn lưu trữ toàn bộ biểu mẫu dưới dạng chuỗi JSON.

Không chắc chắn về yêu cầu của bạn, nhưng phương pháp này sẽ hoạt động trong một số trường hợp.