添加一个布尔字段与检查字段是否不为空？
我们使用需要管理员批准记录的表格，才能将记录公开显示。我想知道什么是最合适的方式来设计这样一个表，其中主要查询是检索已批准（或尚未批准）的记录。添加一个布尔字段与检查字段是否不为空？
假设查询栏将被索引：
- 是否有任何速度的好处是用一个布尔字段？
- 检查列是否为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;
VS
id | title | text | approved | approved_dttm ---------------------------------------
1 | ... | ... | 0 | null
2 | ... | ... | 1 | 2017-01-01 00:00:00 ETC
SELECT * FROM table where approved = 1;
注意：我们并不需要比不批准的批准/等多种状态。没有“需要进一步审查”等。
回答：
问：使用布尔型字段有什么好处吗？
答：
在这种情况下，使用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值及其怪癖并对其进行处理是的“最佳实践”。
回答：
1）添加approved字段只是复制可以从approved_dttm派生的信息，因此从信息的角度来看没有任何意义。
2）从索引的角度来看，您可能会认为布尔（well，tinyint）字段的索引小于索引日期时间字段的索引。然而，这个索引的选择性会很低（只有2个可能的值），因此在实际选择数据时，MySQL很可能会忽略这样的索引。
总而言之，我不会添加额外的布尔字段来指示条目是否被批准。
以上是 添加一个布尔字段与检查字段是否不为空？ 的全部内容， 来源链接： utcz.com/qa/265784.html
