2

我们现在正在构建的其中一件事是寻找人的搜索功能。

从简单开始，我们使用 Linq to 实体进行搜索，如下所示：Entities.People.Where(z=>z.Birthdate < birthdate).ToList()

然后，当添加新的 searchcriteria 时，linq 语句不断增长，现在我们必须重构它，因为没有人再理解它了。

此时，我们必须方便搜索 8 个相关项，例如“你在这里工作吗”、“你会说这种语言吗”、“从这 6 项技能中，你掌握了哪些”等。

所有这些项目都是 SqlServer 中的 1:N 或 N:N 关系，我们正在搜索多个项目，我们想知道你有“多少匹配”。

例如：我们寻找说法语和/或英语和/或德语的人，我们希望得到所有至少有 1 个匹配项的人，对于这些人，我们想知道有多少匹配项（即 3 个中的 1 个或2 / 3) 每个人都有。

此时的问题是：做什么是明智的（数据库中大约有 10.000 人）。

头脑风暴使我们有以下选择：

  1. 在数据库中进行最快的搜索（因此您检索有限数量的记录）并在代码中对其余部分进行排序
  2. 继续使用 Linq 构建
  3. 在 SqlServer 中执行整个操作

有什么提示可以帮助我们入门吗？

4

2 回答 2

1

如果 Linq to Entities 表达式变得过于复杂，这对我来说意味着您的需求正在迅速发展。

鉴于您的数据库的总大小很小（10K 记录非常小），您可能会发现编写返回所有可能匹配的人的 SQL（或 Linq to Entities）语句最有效，并在业务层应用排序.

我说“高效”是因为不过滤数据库端的一些记录不会损失太多（如果数据库包含 10M 条记录并且您返回了相当大的一部分，那将不太正确），并且因为我从方式上感觉到你写了你的问题，你的团队可能更愿意在代码中工作。

于 2012-10-30T15:36:31.660 回答
1

就速度而言，只要您使用已编译的查询，您的select性能就不太可能有太大的不同。Rico Mariani有一篇很棒的文章，他详细介绍了他们为使 LINQ 相对于 SQL 更快所做的所有工作。妙语是，如果您使用的是已编译的 select 语句（就像您应该使用的那样），那么您的运行速度几乎与存储过程一样快 -实际上是原始 SQL 的 93% 。如果您没有使用已编译的选择，那么您应该阅读这篇文章，让您深入了解如何制作它们。未编译的选择查询大约是普通 SQL 的一半，因此可能会有不错的收获。

如果速度不是什么大问题，并且您指的是保持这个听起来复杂的数据库模式一致的组织任务，那么这完全是另一回事。如果是这种情况，那么您可能希望从 SQL 级别开始，至少确保您拥有所有想要的匹配项。这很容易测试，并且 SQL 针对这种搜索进行了优化。当您可以从服务器获得或多或少的即时反馈时，您还会发现更容易确认您的工作，而不必编译和运行您的程序来测试场景。

在你确定你拥有你想要的一切并且没有你不想要的一切之后，你可以处理简单得多的任务，即在 C# 中简单地组织它，使用任何规则来确定候选人的优先级。

编辑：哎呀，我没有看到埃里克的答案与我的非常相似。那好吧。

于 2012-10-30T15:51:49.907 回答