我有MS SQL 2012 DB和文件表。
在申请中有users。
users可以是document managers。user manager可以是documents
document可以有多个managers。 app的用户数限制为50。
我想知道搜索document manager是某个用户（或少数用户）的最佳方式（或最快）。
1）一个文档表和文档管理器对象的附加表。然后搜索
select from document dk
join documentmanager dm on dm.dokid=dk.id and dm.userlogin='xxx'
或
2）不要为管理器对象使用额外的表，而是将每个用户管理器编号从1到50绑定，然后使用serach：
SELECT * FROM documents where (managers & CAST(manager AS BIGINT) <> 0)
经理是2 ^经理人数。
第二个似乎更快更简单，并且不需要额外的表，因此也需要更少的空间。但我不知道我是否在附加表上使用索引，可能会比2更快。当然，63个用户有限制，但请说它不重要。
答案 0 :(得分：1)
第一个想法是如何设计关系数据库。有一个原因 - 它是数据库的更好设计。
你说用户数量的限制并不重要，你不需要超过63个。在我看来，如果你有少于63个，你不需要数据库。您可以从任何文件加载它并将所有信息存储在内存中。 如果尺寸和可扩展性不重要，那么甚至不要使用数据库。
在所有其他情况下，使用经过多年验证的标准关系设计。
答案 1 :(得分：1)
很难说哪一个会更快，至少在记录数量很少的时候。第二种方法有一个更简单的查询，但它不能使用任何索引，因为它必须计算每个文档的表达式的值。
第二种方法可能看起来更容易，但它实际上非常传统。查看第一种方法的表设计，任何具有一点数据库经验的人都可以立即告诉它应该如何工作。任何看第二种方法的人都需要检查查询，以找出＆＃34;魔法＆＃34;表中的数字应该是指。
即使用户数量有限以便第二种方法可用，文档数量也可能随着时间的推移而增长。由于第二种方法中的查询必须检查每个文档，因此当文档数量增加时，它将变慢。另一方面，第一种方法中的查询可以使用索引，因此执行时间主要取决于返回的记录数，而不是表中的记录数。它可以轻松处理包含数百万条记录的表格，甚至可以发现性能上的任何差异。