Lược đồ đầu tiên của bạn là lựa chọn tốt hơn trong cả hai. Tại thời điểm này, bạn không nên lo lắng về các vấn đề hiệu suất. Lo lắng về việc tạo ra một thiết kế tốt, linh hoạt, có thể mở rộng. Có tất cả các loại thủ thuật bạn có thể thực hiện sau để lưu dữ liệu vào bộ nhớ cache và thực hiện các truy vấn nhanh hơn. Sử dụng một lược đồ cơ sở dữ liệu kém linh hoạt hơn để giải quyết vấn đề hiệu suất mà thậm chí có thể không thành hiện thực là một quyết định tồi.
Bên cạnh đó, nhiều (có lẽ là hầu hết) kết quả khảo sát chỉ được xem định kỳ và bởi một số ít người (nhà tổ chức sự kiện, quản trị viên, v.v.), vì vậy bạn sẽ không phải liên tục truy vấn cơ sở dữ liệu cho tất cả các kết quả. Và ngay cả khi bạn đã như vậy, hiệu suất sẽ tốt. Bằng cách nào đó, bạn có thể sẽ phân loại kết quả.
Lược đồ đầu tiên linh hoạt hơn nhiều. Theo mặc định, bạn có thể bao gồm các câu hỏi như tên và địa chỉ, nhưng đối với các cuộc khảo sát ẩn danh, bạn không thể tạo chúng. Nếu người tạo khảo sát muốn chỉ xem câu trả lời của mọi người cho ba câu hỏi trong số năm trăm câu hỏi, thì đó là một truy vấn SQL thực sự đơn giản. Bạn có thể thiết lập xóa theo tầng để tự động xóa các câu trả lời và câu hỏi khi một khảo sát bị xóa. Việc tạo thống kê cũng sẽ dễ dàng hơn nhiều với lược đồ này.
Đây là phiên bản được sửa đổi một chút của lược đồ mà bạn đã cung cấp. Tôi giả sử bạn có thể tìm ra loại dữ liệu nào sẽ đi đâu :-)
surveys
survey_id (index)
title
questions
question_id (index, auto increment)
survey_id (link to surveys->survey_id)
question
responses
response_id (index, auto increment)
survey_id (link to surveys->survey_id)
submit_time
answers
answer_id (index, auto increment)
question_id (link to questions-question_id)
answer
