Thiết kế giản đồ khi người dùng có thể xác định các trường

Question

Ngăn xếp lời chào,

Tôi đang cố gắng tìm ra lược đồ cơ sở dữ liệu tốt nhất cho phép người dùng tạo cuộc khảo sát và giới thiệu chúng cho công chúng. Có một loạt các trường nhân khẩu học "tiêu chuẩn" mà hầu hết các khảo sát (nhưng không phải tất cả) sẽ bao gồm, như Tên, Họ, v.v. Và tất nhiên người dùng có thể tạo số câu hỏi "tùy chỉnh" không giới hạn.

Điều đầu tiên tôi nghĩ đến là một cái gì đó như thế này:

Survey 
    ID 
    SurveyName 

SurveyQuestions 
    SurveyID 
    Question 

Responses 
    SurveyID 
    SubmitTime 

ResponseAnswers 
    SurveyID 
    Question 
    Answer 

Nhưng điều đó đang diễn ra để hút mỗi khi tôi muốn truy vấn dữ liệu ra. Và có vẻ như gần một cách nguy hiểm để Inner Platform Effect

Một cải tiến sẽ bao gồm nhiều lĩnh vực như tôi có thể nghĩ đến trước trong các câu trả lời bảng:

Responses 
    SurveyID 
    SubmitTime 
    FirstName 
    LastName 
    Birthdate 
    [...] 

Sau đó, tại các truy vấn ít nhất là cho dữ liệu từ các cột điểm chung là đơn giản, và tôi có thể truy vấn, nói rằng, tuổi trung bình của tất cả mọi người đã từng trả lời bất kỳ cuộc khảo sát nào mà họ đã đưa ra ngày sinh của họ.

Nhưng có vẻ như điều này sẽ làm phức tạp mã một chút. Bây giờ để xem câu hỏi nào được hỏi trong một cuộc khảo sát, tôi phải kiểm tra xem các trường phản hồi chung nào được kích hoạt (sử dụng, tôi đoán, một bitfield trong Survey) VÀ cái gì trong bảng SurveyQuestions. Và tôi phải lo lắng về các trường hợp đặc biệt, như nếu ai đó cố gắng tạo câu hỏi "tùy chỉnh" sao chép câu hỏi "phổ biến" trong bảng Câu trả lời.

Đây có phải là điều tốt nhất tôi có thể làm không? Tui bỏ lỡ điều gì vậy?

Answer 1

Giản đồ đầu tiên của bạn là lựa chọn tốt hơn cho cả hai. Tại thời điểm này, bạn không nên lo lắng về vấn đề hiệu suất. Lo lắng về việc 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 truy vấn nhanh hơn. Sử dụng lược đồ cơ sở dữ liệu ít linh hoạt hơn để giải quyết vấn đề hiệu suất mà thậm chí không thể hiện thực hóa là một quyết định tồi.

Bên cạnh đó, nhiều kết quả khảo sát chỉ được xem định kỳ và bởi một số ít người (tổ chức sự kiện, quản trị viên, v.v.), vì vậy bạn sẽ không 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, hiệu suất sẽ tốt. Bạn có lẽ sẽ phân trang các kết quả bằng cách nào đó.

Giản đồ đầu tiên linh hoạt hơn nhiều. Bạn có thể, theo mặc định, 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 có thể chỉ đơn giản là không tạo chúng. Nếu người tạo khảo sát chỉ muốn xem câu trả lời của mọi người cho ba câu hỏi trong số năm trăm, đó là một truy vấn SQL thực sự đơn giản. Bạn có thể thiết lập tính năng xóa tầng để tự động xóa câu trả lời và câu hỏi khi cuộc 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 giản đồ bạn đã cung cấp. Tôi cho rằng bạn có thể tìm ra loại dữ liệu nào đi tới :-)

 
    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 

Answer 2

Tôi khuyên bạn nên luôn sử dụng phương pháp chuẩn hóa cho giản đồ cơ sở dữ liệu của mình và sau đó quyết định xem bạn có cần tạo giải pháp cho lý do hiệu suất hay không. Tối ưu hóa sớm có thể nguy hiểm. Cơ sở dữ liệu không chuẩn hóa sớm có thể là thảm họa!

Tôi khuyên bạn nên tuân thủ lược đồ gốc và sau đó, nếu cần, tạo bảng báo cáo là phiên bản không chuẩn hóa của giản đồ chuẩn hóa của bạn.

Answer 3

Một thay đổi có thể hoặc không thể giúp đơn giản hóa mọi thứ sẽ không liên kết ResponseAnswers với SurveyID. Thay vào đó, hãy tạo ID cho mỗi câu trả lời và cho mỗi câu hỏi và để bảng ResponseAnswers của bạn chứa các trường ResponseID, QuestionID, Answer. Mặc dù điều này đòi hỏi phải giữ các mã định danh duy nhất cho mỗi đơn vị nó sẽ giúp giữ cho mọi thứ được chuẩn hóa hơn một chút. Câu trả lời câu trả lời không cần phải liên kết với cuộc khảo sát mà họ chỉ trả lời câu hỏi cụ thể mà họ đang trả lời và thông tin phản hồi mà họ được liên kết.

Answer 4

Tôi đã tạo hệ thống khảo sát khách hàng tại công việc trước đây của tôi và đã đưa ra một giản đồ rất giống với những gì bạn có. Nó được sử dụng để gửi các cuộc khảo sát (trên giấy) và lập bảng các câu trả lời.

Một vài khác biệt nhỏ:

• Khảo sát đã KHÔNG nặc danh, và điều này đã được thực hiện rất rõ ràng trong các hình thức in. Nó cũng có nghĩa là dữ liệu nhân khẩu học trong ví dụ của bạn đã được biết trước.

• Có một nhóm câu hỏi được đính kèm với bản khảo sát, do đó, một câu hỏi có thể được sử dụng cho nhiều khảo sát và phân tích độc lập với khảo sát mà nó xuất hiện.

• Xử lý các loại câu hỏi khác nhau thú vị - chúng tôi có thang tỷ lệ 1-3 (ví dụ: Tồi tệ hơn/Tương tự/Tốt hơn), tỷ lệ 1-5 (Rất tệ, Xấu, Tốt, Rất tốt), Có/Không, và Bình luận.

  Có mã đặc biệt để xử lý các nhận xét, nhưng các loại câu hỏi khác được xử lý chung bằng cách có một bảng các loại câu hỏi và một bảng câu trả lời hợp lệ khác cho từng loại.

Để làm cho truy vấn dễ dàng hơn, bạn có thể tạo chức năng trả về phản hồi dựa trên ID khảo sát và ID câu hỏi.