Question

我有一个实体框架查询，其条件如下：

var filtered = collection.Where(sp => sp.SubscriptionStartDate < DateTime.UtcNow && 
    sp.SubscriptionEndDate >= DateTime.UtcNow)

Vs以上。

var currentUtcDate = DateTime.UtcNow;
var filtered = collection.Where(sp => sp.SubscriptionStartDate < currentUtcDate  && 
    sp.SubscriptionEndDate >= currentUtcDate)

第一个将转换为SYSUTCDATETIME（），另一个将通过参数传递日期。我总是做第二个场景，两个条件的日期完全相同，而不是纳秒秒，但我正在做出这个假设。

这会影响性能，因为我每次运行时都会将不同的参数传递给查询吗？哪种是最佳做法？

Answer 1

尽可能地，我总是尝试将日期设置和日期检查推送到数据库，因为我有一些项目，其中有多个软件正在访问数据库，但没有一个项目只有一个在不同机器上访问数据库的软件，这些数据库没有保持同步（例如，如果数据库是负载平衡的）。（或者我实际上并不关心时间戳的地方）。

因此，数据库一直是One-True-UTC-Rule-all-All可以存在的明显位置。

这也为我提供了更多的灵活性，包括我做或不做的触发器，列默认设置，带外操作的清理代码等等。

但是，其他应用程序可能完全相反，单个应用程序使用几个完全独立的数据库。

如果（最常见的话）我有一个应用程序，单个数据库往往仍然将数据库作为唯一的时间提供者，即使它们在同一台机器上运行。通常，这些系统会变成单个数据库，多个应用程序情况，而不是变成单个应用程序，多个数据库。（同样，我不计算在数据库中发生集群或负载平衡的情况;我解决了将它们分开保持同步的问题，因此就外部而言，它们仍然是单个数据库）。

无论哪种方式，基本原则是假设只有系统的一部分知道它是什么时间，至少对于与两个部分相关的事项（如果应用程序执行与时间无关的其他与时间相关的事情）实体，然后合理的同步量就足够了。）

总结：

多个应用，单个数据库：使用数据库上的时间。（代码示例1）
单个应用，多个数据库：使用应用中的时间。（代码示例2）
单个应用程序，单个数据库：在数据库上使用时间（因为您更有可能演变为案例1而不是案例2）。
多个应用程序，多个数据库：这样一个广泛分布的系统需要以非常强大和容错的方式建立在设计中的时间规则，我不能回答只是建议一个或另一个，尽管我仍然更有可能将我的解决方案基于第一种方法而不是第二种方法。

至于表现，这些事情几乎是微不足道的。一个会比另一个更快，因为在现实世界中需要花费时间的任何两个东西比另一个更快，但它可能不会是一致的，哪个和它肯定会在如此小的程度上你不会在乎。如果你在给定的查询中有一个大量这样的参数，它可能会变得很重要，但是如果它确实开始变得重要，你会想要检查并找出哪个更适合你，而不是比一些计算机科学理论知道哪些在大多数时候对普通开发人员更有效。你也可能希望进一步改变这种方法，以避免这个问题。

Answer 2

查询中的变量将转换为参数化SQL。此必须才能在数据库中实现计划重用。您的日期变量就像这方面的任何其他变量一样。它最终为datetime参数。

我同意Jon Hanna所说的关于问题的最佳实践部分的内容，并没有任何补充。从表现的角度来看，这无关紧要。

Answer 3

唯一显着的区别是sql时钟与运行程序的机器的时钟差别很大。

LINQ在UTC日期传递或使用DateTime.UtcNow？

3 个答案: