我們的數據庫包含一個用於存儲用戶特定數據的USERS表，並且每個用戶都有一個狀態，即active或inactive。使用USERS表中的is_active布爾值字段來指示狀態即可。同時，對於「不活躍」的用戶，我們將其他信息保留在另一個字段中，這對於處於相反（「活動」）狀態的用戶來說是不相關的（因此設置爲空）。DB設計問題
我的問題：更好的設計是保留USERS表中的is_active布爾型字段以清楚地指示狀態，或者根據可用的次要標準實際推導出狀態（附加信息的可用性總是，只有當用戶處於狀態「不活躍」）？
也就是說，它看起來像is_active字段是關於數據庫規範化的冗餘，但同時，可用於派生它的邏輯在第一次掌握時並不那麼明顯，並且使得關於狀態看起來很麻煩並且包含非明確的邏輯。
一般來說，我寧願有一個具體的標誌爲此，由於其他人解釋的各種原因。
但除此之外......你有沒有特別包含這兩種類型中的一種的查詢（例如「非活動用戶列表和已經創建超過一年前」或「發送電子郵件給所有人在上個月還沒有登錄的活躍用戶「）？
如果是，那麼（或包括）字段上的索引肯定會更有效。
我認爲最好不要做這個布爾值，以防萬一你最近發現你需要模擬第三種或第四種「用戶」。
保留Is_Active字段。數據庫有改變的方式以適應隨着時間的推移而產生的需求。誰知道，您可能想要使用不相關的字段來存儲有關活動用戶的信息。
如果有人不活躍然後再次變爲活動狀態，則其他字段仍然可以填寫。保留is_active字段。
這是一個很好的觀點。他們可能沒有考慮到這一點。 – 2012-03-07 16:06:29
@pheedbaq，我注意到有關設計數據庫或者數據庫對象的非數據庫專家的一件事情，他們經常忘記考慮如何在設計中維護或更改數據。 – HLGEM 2012-03-07 18:35:08
最好的方法是存儲和使用有關活動的數據。在某些應用程序中，這可能是付款。在其他情況下，它可能是上次登錄時間。 （關於不活動的數據不是我正在談論的。）
接下來最好的是明確的標誌。但布爾數據類型沒有足夠的不同值（duh）使某些查詢優化器比布爾列上的全表掃描更好。一些dbms支持部分索引或基於函數的索引，這些索引可以提高布爾的性能;如果您使用標誌並且您的dbms支持它，請使用它。
標誌看起來像數據，但通常它們是一種僞數據。
我的數據庫中有類似的字段，對最終用戶很有用，所以他們可以一目瞭然地瞭解發生的情況。如果你的數據庫管理系統支持它，我會使is_active成爲一個計算字段（基於你的非活動標準）和一個索引。您可能必須製作計算字段所引用的用戶定義函數，這可能會阻止在其上放置索引，但我認爲您應該避免將計算字段用作查詢中的條件。
製作一個包含您的非活動記錄標準的視圖，並返回它適用的所有記錄的PK。然後將該視圖用作需要標準的任何查詢的地方。如果性能成爲問題，您可以查看索引視圖來加快速度。
取決於您的最終目標是什麼。我不認爲這會使得它在具有is_active字段時顯着減少標準化，因爲您不是跨表重複數據。此外，它使得與數據庫交互更容易，讓您有一個字段可以檢查用戶是否處於活動狀態。它還避免了在用戶未激活時附加字段未更新的問題（假設is_active字段不爲空）。但後來我總是被教導說，第三種正常形式是應用程序性能和數據完整性之間的一個很好的折衷點。 – Brian 2012-02-21 22:23:10