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

Question

我有一个实体框架查询,其条件如下:

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

比.

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

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

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

Answer 1

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

因此，数据库一直是“One-True-UTC-to-Rule-them-All”可以生存的明显地方。

这也为我在触发器、列默认值、带外操作的清理代码等方面提供了更大的灵活性。

然而，其他应用程序可能具有完全相反的情况，单个应用程序使用多个完全独立的数据库。

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

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

总之：

1. 多个应用程序，单个数据库：使用数据库上的时间。（代码示例1）
2. 单个应用程序，多个数据库：使用应用程序中的时间。（代码示例2）
3. 单个应用程序，单个数据库：使用数据库上的时间（因为您更有可能发展为情况 1，而不是情况 2）。
4. 多个应用程序，多个数据库：这样一个广泛分布的系统需要以一种非常稳健和容错的方式将有关时间的规则内置到设计中，我不能只建议其中之一来回答，尽管我仍然会更愿意我的解决方案可能基于第一种方法而不是第二种方法。

至于性能，这些问题几乎是微不足道的。一个会比另一个更快，因为在现实世界中任何两件事都需要时间，其中一个比另一个更快，但哪个是哪个可能不会一致，而且肯定会在很小的程度上一致，以至于你不会在意的。如果您在给定的查询中拥有大量此类参数，那么它可能会开始变得重要，但如果它确实开始重要，您将想要检查并找出哪个更适合您，而不是做一些计算机科学理论了解哪一个在大多数情况下对普通开发人员来说效果更好。您可能还需要进一步改变方法，以避免首先出现大量的情况。