在NHibernate中查询对象存在的最快方法

Question

我正在寻找最快的方法来检查是否存在对象。 这个场景很简单，假设一个目录工具，它读取当前的硬盘。当找到一个目录时，它应该被创建，或者，如果已经存在，则被更新。

首先让只专注于创建部分：

public static DatabaseDirectory Get(DirectoryInfo dI) 
    { 
     var result = DatabaseController.Session 
         .CreateCriteria(typeof (DatabaseDirectory)) 
         .Add(Restrictions.Eq("FullName", dI.FullName)) 
         .List<DatabaseDirectory>().FirstOrDefault(); 

     if (result == null) 
     { 
      result = new DatabaseDirectory 
         { 
          CreationTime = dI.CreationTime, 
          Existing = dI.Exists, 
          Extension = dI.Extension, 
          FullName = dI.FullName, 
          LastAccessTime = dI.LastAccessTime, 
          LastWriteTime = dI.LastWriteTime, 
          Name = dI.Name 
         }; 
     } 
     return result; 
    } 

这是去有关方式：

• 速度
• 相关分离

什么来头脑是以下几点：扫描将始终“整体”执行。意思是，在驱动器C的扫描期间，我知道没有新的东西被添加到数据库（来自其他进程）。因此，在扫描之前“缓存”所有现有的目录可能是一个好主意，并以这种方式查找它们。另一方面，这可能不适合大数据集，如文件（将会是600.000或更多）...

也许某些性能增益可以通过使用“索引列”或类似的东西来实现，但我对这个话题不太熟悉。如果有人有一定的参考，只是点我朝着正确的方向...

谢谢， 克里斯

PS：我使用NHibernate的，流利的接口，自动映射和SQL Express的（可切换到全屏SQL）

注意： 在给定的问题中，路径不是数据库中的ID。该ID是一个自动增量，我不能改变这个要求（其他原因）。所以，真正的问题是，什么是最快的方法“检查对象是否存在等，其中ID是不知道，只是该对象的属性”

而且配料是可能的，通过选择像“以C：Testfiles开头”这样的大团体，但问题仍然存在，我怎么事先知道这个集合有多大。我不能选择“最大1000”，并检查这个缓冲字典，因为我可能会“击中搜索目录旁边......”我希望这个问题是明确的。最重要的部分是缓冲确实影响了性能。如果是这样，是否有意义加载整个数据库在字典中，只包含PATH和ID（即使有1.000.000的对象，我认为..）

Answer 1

首先，我高度建议你（任何人使用NH，真的）阅读Ayende关于differences between Get, Load, and query的文章。

在你的情况，因为你需要检查存在，我会用.Get(id)而不是查询选择一个单个对象。

但是，我想知道是否可以通过利用问题域的一些知识来提高性能。如果您要扫描整个驱动器并检查数据库中的每个目录是否存在，则可以通过批量操作获得更好的性能。也许创建一个只包含你的对象的PK的DTO对象，以进一步减少数据传输/处理。例如：

Dictionary<string, DirectoryInfo> directories; 
session.CreateQuery("select new DatabaseDirectoryDTO(dd.FullName) from DatabaseDirectory dd where dd.FullName in (:ids)") 
    .SetParameterList("ids", directories.Keys) 
    .List(); 

然后只删除与返回的ID值相匹配的元素以获取不存在的目录。您可能必须根据您的输入集的大小（几乎可以肯定的文件）将流程分成更小的批次。

就分离问题而言，只需将操作保留在存储库级别即可。有一个像SyncDirectories这样的方法，它需要一个集合（可能是一个Dictionary，如果你按照上面的方式）来处理更新数据库的过程。这样，如果您将来找到更快的方法，您的更高应用程序逻辑就不必担心它是如何工作的，并且不会受到影响。