兩種反模式之間的選擇:過度設計與過度優化
有時我需要保持狀態,例如 IsVerified 標誌。
有兩種選擇:
布爾值(或位)
優勢:最小最快
…但在理論上“過度優化”,因此是一個糟糕的論點。
可為空的日期時間
IsVerifiedOn -> NULL 未驗證,任何值都表示已驗證。
優點:您將來可能會遇到一種情況,您會突然遇到一個有用的情況,即您實際上知道該帳戶何時已通過驗證。
…但理論上“過度設計”(你不需要它),你應該只在你真正需要它的時候添加它。
那麼在這兩種邪惡之間呢?什麼是最好的開始?
我相信你可能“想多了”。我從未聽說過“過度優化是一種反模式”這句話,我通常不同意這一點。
與其過分擔心反模式,不如為您的案例架構師並保持合理。如果您知道
IsVerifiedOn
在不久的將來您將永遠不會合理地需要 datetime 欄位,那麼使用IsVerified
bit 欄位可能就可以了。如果擁有該IsVerifiedOn
領域有合理的潛在用途,那麼請改用這樣的領域。這裡沒有正確或錯誤的答案,這又取決於對您的案例來說什麼是合理的。這是另一種甚至可以考慮的反模式,它將您提到的兩個從水中吹出來:它被稱為“一個領域多用途”。這意味著它所說的,即從技術上講,讓一個欄位具有多種用途在技術上是一種相當大的反模式,例如您的
IsVerifiedOn
專欄描述所暗示的。第一個目的是辨識一行是否被驗證,第二個目的是辨識它何時被驗證。這被認為是反模式的一個原因是,有一天該欄位可能具有一個很好地滿足一個目的的值,同時打破了邏輯或對另一個目的沒有意義。例如,在您的情況下,您可能有另一個表從您的
IsVerifiedOn
欄位派生而來。第二個表只保存第一個表中最後 10 個已驗證行的記錄。現在有人決定通過IsVerifiedOn
清空最後幾條記錄的欄位來取消驗證您的第一個表,但他們忘記從第二個表中清除最後幾條記錄。現在您失去了數據完整性。針對這種反模式的最佳實踐實際上建議同時實現
IsVerified
欄位和VerifiedOn
欄位以分別維護這兩個目的。但同樣,這也取決於您在合理範圍內的實際案例,並且並不總是必須遵守。如果你總是試圖合理地設計你的模式,你就不必考慮太多反模式。(Ps 我實際上給出了一個關於“一個欄位多用途”反模式的非常弱的例子,但是有很多現實的數據完整性破壞事情可能會因此而發生。所以儘管我的例子很糟糕,但希望它仍然傳達這個想法。)