這是數據庫設計的不好方法嗎？

Question

我必須為我的大學構建一個應用程序，該應用程序將計為持續1個月的課程的課程學分。 在此應用程序中，我必須為用戶提供一種保存教師班級跟進評估的方法，這是一個人去教室檢查老師並在某些欄中打勾。

一個例子是：

教學方面：
顯示順序並遵循課程順序：是否觀察
給出明確的例子：是否觀察
讓學生參與討論：是否觀察

如果用戶（一個進行評估的用戶）選擇“是”，則“觀察值”中不會寫入任何內容，但是如果用戶選擇“否”，則他必須編寫觀察值而不會失敗。

如何在數據庫中處理此問題？ 我對過度規范化有疑問。 ：x在我繼續進行該項目之前，現在歡迎任何建議。

到目前為止，我的計划是只創建一個名為Followup的大表，該表具有Microsoft SQL中所有這些帶有BIT數據類型的“方面”，並且對於每個方面都可以為null的ShowOrderSequenceObservation字段。 O_O我只是想着就覺得很臟，所以我轉向您的其他開發人員。 謝謝！

Answer 1

我會做這樣的事情：

實際記錄表-請注意，從學生的角度來看，這是匿名記錄

| record_id | question_id | YESNO | observation | teacher_id |

問題表。

| question_id | question_string |

教師表：

| teacher_id | teacher_string |

在一般情況下，我還將更新學生表以記錄“已記錄”，並將所有答案插入一個事務中。 這樣既可以保留學生的匿名性，又可以獲取數據。

編輯-我不知道該如何整理ORM。 如果要開發它，我會在10-30個小時內通過perl和直接sql訪問來破解它。 大多數時間將花費在HTML格式上。

Answer 2

聽起來像是時間與質量的古老問題。 歸一化的表格肯定是快速且容易的，但是具有類別和問題表的歸一化表格將具有靈活性。 您可以將它用於其他用途，可以即時設置新的問題類型，並可以提高您的成績。

如果您認為可以使用非規范化表來獲得所需的內容，那我就去做。 這不是生產系統，業務需求在其生命周期中不會改變。 但是，如果您想尋求最高榮譽的解決方案，我將其標准化。

順便說一句，在每個選項的末尾添加<br>使其更具可讀性。

Answer 3

您知道規范化不僅適用於大型企業級數據庫（我知道您知道:)。 歷史表明，如果不進行標准化，則會出現異常。 從5NF開始並從那里“優化”，盡管我懷疑您會發現不需要優化。

我懷疑提出的設計將不適合其預期的目的，例如數據分析。 嘗試針對它編寫一些典型的SQL查詢（例如，所有教學問題的平均觀察長度，然后是所有問題的平均長度），您會發現這很痛苦：巨大的CASE語句，表UNION編寫了很多遍，...很可能您將結束編寫VIEW來規范化數據！