我们现在正在构建的一件事是搜索功能，以寻找人。
当开始简单时，我们使用Linq来搜索实体，如下所示：Entities.People.Where(z=>z.Birthdate < birthdate).ToList()
然后，当添加新的searchcriteria时，linq语句会增长和增长，现在我们必须重构它，因为没有人再理解它了。
此时，我们必须方便搜索8个相关项目，例如“你在这里工作”，“你会说这种语言吗”，“这6种技能，你掌握哪些技能”等。
所有这些项目在SqlServer中都是1：N或N：N关系，我们正在搜索多个项目，我们想知道你有多少匹配。
例如：我们寻找说法语和/或英语和德语的人，我们希望得到所有至少有1场比赛的人，而对于那些人，我们想知道有多少场比赛（即1场比赛）每个人都有3或2个中的3个人。
此时的问题是：什么是聪明的事情（数据库中约有10,000人）。
头脑风暴引导我们选择以下方案：
任何让我们入门的提示？
答案 0 :(得分：1)
如果Linq to Entities表达式变得过于复杂，那对我来说意味着你的需求发展得相当快。
鉴于数据库的总大小很小（10K记录非常小），您可能会发现编写SQL（或Linq to Entities）语句最有效，该语句返回所有可能匹配的人，并应用排序业务层。
我说“高效”，因为你没有因为没有过滤数据库端的一些记录而损失太大（如果数据库包含10M记录并且你返回了很大一部分，那就不那么真实了），因为我感觉不到从您撰写问题的方式来看，您的团队可能更愿意使用代码。
答案 1 :(得分：1)
就速度而言，只要您使用已编译的查询，您的select性能就不会太差异。有一个great article from Rico Mariani，他详细说明了他们所做的所有事情，以使SQL在SQL方面更快。如果你使用的是编译的select语句（就像你应该的那样），那么你的运行速度与存储过程一样快 - 93% as fast as raw SQL。如果您没有使用已编译的选择，那么您应该阅读this article以了解如何制作它们。未编译的选择查询大约是普通SQL的一半，因此可以获得很好的收益。
如果速度不是问题，并且你指的是保持这个复杂的数据库架构符合线的组织任务，那么另一件事就是altogther。如果是这种情况，那么您可能希望从SQL级别开始，至少确保您拥有所需的所有匹配项。这很容易测试，SQL针对这种搜索进行了优化。当您可以从服务器获得或多或少的即时反馈时，您也会发现更容易确认您的工作，而不必编译和运行您的程序来测试场景。
在你确定你拥有你想要的一切，而你没有任何东西之后，你可以处理更简单的任务，只需在C＃中组织它，你可以使用任何规则来优先考虑候选人。
编辑：哎呀，我没有看到Eric有一个与我非常相似的答案。哦，好吧。