一位同事正在为我们所有的数据库表添加一个掩码。从理论上讲，我们可以跟踪整个系统中每行的某些属性。例如......
这是个好主意吗？这种方法有益于其他用途吗？
我的偏好是这些属性显然很重要，并且为每个属性设置专用列是合理的，可以让开发人员更清楚地了解这些属性。
答案 0 :(得分：10)
不是，不。
您只能在其中存储位，而且只能存储位数。因此，在我看来，它似乎要求很多应用程序级别的麻烦，以后跟踪每个人的意思和后来的潜在滥用，因为“嘿，他们无处不在”。每个表上的每个位掩码是否会对每个位使用相同的定义？每张桌子都不一样吗？当你用完比特时会发生什么？添加另一个？
你可能做了很多潜在的事情，但它引出了一个问题“为什么这样做，而不是确定我们现在将用于那些位 只是让它们成为合适的列？“无论如何，你并没有真正规避架构更改的可能性，因此它似乎正试图解决一个你无法真正“解决”的问题，特别是没有使用位掩码。
你提到的每一件事都可以（并且应该）用数据库中的真实列来解决，而且这些事情比“BitMaskOptions字段的第5位更加自我记录”。
答案 1 :(得分：7)
专用列 更好，因为它无疑更明显，更不容易出错。 SQL Server already stores BIT columns efficiently，因此性能不是问题。
我可以看到的唯一一个用于位掩码的参数是每次添加新标志时都不必更改数据库模式，但实际上，如果你要添加新标记，那么通常会出现问题。
答案 2 :(得分：4)
不，它甚至不是一个好主意IMO。每列应代表一个概念和值。位掩码具有各种性能和维护问题。新开发人员如何理解每个位的含义？你如何防止有人意外混淆比特顺序的含义？
拥有多对多关系或单独的列而不是位掩码会更好。您将能够对其进行索引，启用参照完整性（取决于方法），轻松添加新项目并更改结果的顺序以适应不同的报告等。