添加一個布爾字段與檢查字段是否不爲空？

我們使用需要管理員批准記錄的表格，才能將記錄公開顯示。我想知道什麼是最合適的方式來設計這樣一個表，其中主要查詢是檢索已批准（或尚未批准）的記錄。添加一個布爾字段與檢查字段是否不爲空？

假設查詢欄將被索引：

是否有任何速度的好處是用一個布爾字段？
檢查列是否爲NULL違背最佳實踐？

例如：

id | title | text | approved_dttm 
--------------------------------------- 
1 | ... | ... | null 
2 | ... | ... | 2017-01-01 00:00:00 ETC 


SELECT * FROM table where approved_dttm IS NOT NULL;

id | title | text | approved | approved_dttm 
--------------------------------------- 
1 | ... | ... | 0  | null 
2 | ... | ... | 1  | 2017-01-01 00:00:00 ETC 


SELECT * FROM table where approved = 1;

注意：我們並不需要比不批准的批准/等多種狀態。沒有「需要進一步審查」等。

來源

2017-06-20 BMannell

恕我直言，在批准的日期，布爾添加冗餘數據（如果批准日期設置，它必須被批准）。 NULL被廣泛使用，這是人們共同努力的共同點。 –

如果您認可您無法使用approved_dttm，您會怎麼做？如果答案是什麼，我會放棄它。 –

問：使用布爾型字段有什麼好處嗎？

答：

在這種情況下，使用approved列與approved_dttm IS [NOT] NULL列的任何查詢都不可能獲得「速度優勢」。

儘管批准列的附加字節可以忽略不計（假設定義爲TINYINT，那麼額外的字節並不會真正影響塊中「適合」的行數）......在該列上的索引不會忽略不計。這將需要額外的塊（空間），並會增加維護索引條目的開銷。

我們不能排除一些特殊的情況，即添加該列會有好處，但總的來說，考慮到提供的信息，否，添加該列沒有「速度優勢」。

（我們在這裏討論冗餘數據和更新異常......在第三範式的表單中添加（冗餘）列蒼蠅，以及熟悉的口頭禪「每個屬性都依賴於所以幫助我Codd「）

問：檢查列是否爲NULL違背最佳實踐？

答：

這並不違背任何我知道的「最佳實踐」。 NULL和三值布爾邏輯一直存在（自1970年EFCodd首次創造「關係」以來，1977年System/R和Oracle的出現，以及1983年DB2的出現......）

某些集合的應用程序開發人員可能不喜歡（或理解）如何處理NULL值的細微差別。確實將列定義爲NOT NULL可能會減輕他們的負擔。但在我的書中，「避免處理NULL」是而不是是「最佳實踐」。

我們注意到，有些數據庫實現有一些怪癖，沒有使用索引來滿足col IS NULL謂詞。但這些怪癖通常通過適當定義的索引和仔細書寫的查詢來克服。瞭解NULL值及其怪癖並對其進行處理是的「最佳實踐」。

來源

2017-06-20 15:47:40 spencer7593

1）添加approved字段只是複製可以從approved_dttm派生的信息，因此從信息的角度來看沒有任何意義。

2）從索引的角度來看，您可能會認爲布爾（well，tinyint）字段的索引小於索引日期時間字段的索引。然而，這個索引的選擇性會很低（只有2個可能的值），因此在實際選擇數據時，MySQL很可能會忽略這樣的索引。

總而言之，我不會添加額外的布爾字段來指示條目是否被批准。

來源

2017-06-20 15:32:16 Shadow

添加一個布爾字段與檢查字段是否不爲空？

回答

相關問題