2

我有这个查询

var temp = from x in ActiveRecordLinq.AsQueryable<Circuits>()
                       where x.User_Created == false
                       orderby x.Description
                       select x;

从 NHibernate Profiler
查询持续时间
- 仅数据库：7 毫秒 -
总计：835毫秒

生成的查询： 

SELECT   this_.Circuit_ID     as Circuit1_35_0_,
     this_.[Description]  as column2_35_0_,
         this_.[User_Created] as column3_35_0_
FROM     dbo.Circuit this_
WHERE    this_.[User_Created] = 0 /* @p0 */
ORDER BY this_.[Description] asc

这似乎是一个非常简单的查询。它返回 6821 行。我使用它只是为了填充一个下拉列表。

提前致谢

4

3 回答 3

2

好的，如果您坚持使用 7k（我真的相信您应该停下来重新考虑您的设计......但是......），您可以尝试执行 HQL 查询来从对象中选择您需要的字段，而不是查询对象本身。

使用您编写的查询，nHibernate 正在从数据库中加载数据，正如您所指出的那样，这发生得非常快。但是 THEN 基于您编写的 Linq 查询，它正在初始化、填充和返回 7k 电路对象。这可能需要一段时间......

而且由于在这种情况下您实际上并没有以任何有意义的方式使用“对象”（只是下拉列表的文本和值对），您真的不需要 nHibernate 来构建对象。

尝试更改您的代码以仅使用 HQL 或 LinqToNHibernate 返回文本/值对。

HQL 看起来像这样：

select c.description, c.id from Circuit c
where c.ordercreated = false
orderby c.description

我知道你也可以用 LinqToNhibernate 做到这一点，我只是手头没有任何简单的例子。

于 2010-10-05T14:45:01.930 回答
1

等等...您将近 7k 项放在下拉列表中？我理解正确吗？

如果是这样，是否可以使用带有 ajax 或类似设计的依赖下拉列表？

如果这是在网络上，您可能正在查看需要传输到客户端计算机的相对较大的页面，因此优化 NH 查询可能是一个过早的优化......

于 2010-10-04T18:34:30.933 回答
1

下拉列表中的 7k 个条目不利于用户体验。由于您已经按描述订购，我假设您的用户已经（至少部分地）知道他们想要选择什么。所以给出一个完整的列表实际上是在阻碍用户。

既然你问什么是自动完成器

想象一个用户输入多个字符的输入字段。当用户键入他想要的内容时，查询将触发。此字符串参数将用于进一步限制结果集的大小。

所以你的查询实现是这样的伪代码：

//passedParameter => "%foo%"
var temp = from x in ActiveRecordLinq.AsQueryable<Circuits>()
              where x.User_Created == false
                and x.Description like passedParameter
              orderby x.Description
              select x;

查询的实际实现以及您决定实现 '%foo%' 或 'foo%' 等都是您的决定。

用户体验将被简化为在输入字段中写入“foo”，结果将仅获取Circuits用户将选择他想要的内容的相关内容。如果结果集仍然太大，用户可以将“b”添加到已经键入的“foo”中，从而生成一个“foob”，再次触发查询，返回一个更有限的结果集。

当您在 google 上键入时，它会即时为您提供建议，它是一个自动完成器实现

于 2010-10-05T15:00:46.483 回答