很明显，为此使用按位运算符，因为基本上这是标志枚举在内部使用的。我发现了两种方法可以完成此任务：
-- Set up the testing table and fill it up with some example data
create table #Flags (Flag int)
insert into #Flags values (1),(2),(3),(4),(5),(6),(7),(8),(9),(10)
-- These both return the records with Flag 2,8, and 10
select * from #Flags where Flag|10 = 10
select * from #Flags where Flag&10 = Flag
我不是数据库管理员，所以我想知道是否有更好的方法来实现这一目标？如果没有，那么哪个将提供最佳性能？ （我该如何自己测试？）
仅当对象可以同时具有多个状态时，基于位的标志才真正有价值。
在这种情况下，您也可以；
这具有仅存储1个字段的优点，但每个客户端都必须解码该值的缺点。
如果将其存储为字符串，则具有以下优势：其他客户端更容易解码数据，DB管理员，报表创建者等（以及可能直接访问DB的用户）更容易读取数据。即使存储为数字，也更易于阅读。
但是如果您的枚举仅表示一个状态，则不需要按位方法。
然后您可以；
这很简单，但是不支持数据库规范化主体。如果仅将状态存储在单个对象类型（表）中，则可以。
这符合数据库规范化实践，如果/当您添加更多枚举时，将来可以在数据库中实现更好的可扩展性。如果枚举可从多个对象类型（表）访问，则应使用并且。]
很明显为此使用按位运算符，
实际上不是。它与SQL的一切都背道而驰，包括有效地使用索引-您通常不会在内存中表示这些内容。显而易见的是，每个标志字段使用一个布尔值字段。
我不是数据库管理员，所以我想知道
数据库管理员负责管理数据库。您是在说您不是一个喜欢数据库的开发人员。指责自己不是管理员，就像告诉“我不是机械师，所以我不知道从A到B的汽车的最佳行驶方式”。管理员管理，程序员开发。
在SQL中，程序员的开发方式通常取决于程序员如何使用它。 SQL将在内部将多个布尔字段存储为某种标志枚举，但这允许人们设置任何打包解决方案都不允许的各种索引。索引是快速筛选的关键难题，不需要进行表扫描。
在更现代的SQL Server版本中，您可以设置一个压缩字段和一个函数以提取一个值并为定义为使用此函数的字段建立索引。