使用数据库与内存中已有的数据进行搜索

Question

快速版本：
在已经将一堆分层数据加载到内存中的情况下，查询源数据库以通过所述数据执行搜索还是仅搜索内存中已存在的数据更好？

完整版本：
首先，介绍我正在使用的数据的一些背景知识：
我正在处理两种类型的实体，我们将它们称为P和S。它们按层次结构排列，其中S可以具有一组S作为子级，也可以具有一组P作为子级。 P个只能有其他P个孩子。下面是一个简单的图来说明这一点： 每个P和每个S都有一个名称和一个ID，以及其他一些简单的属性。

手头的任务：
我需要允许用户搜索P的名称，然后显示匹配结果列表以及P 路径的字符串表示形式。类似于文件/文件夹路径。

数据结构：
在SQL Server中，这些元素存储在两个表中，一个表用于P，一个表用于S。这些表本质上是自引用的，这意味着需要递归例程来跟踪树的任何元素，但是在某些时候，树从P表跳到S表，然后到达实际根。
在代码中，为每个P和S创建一个对象，并通过给每个孩子一个对其父对象的引用，以及每个父辈对其孩子的列表的引用，将它们链接在一起。 >

在给用户机会进行搜索之前，程序已经需要加载并显示所有这些数据。

当用户搜索时，我可以：
（a）在SQL Server中查询匹配的P的列表，并让查询通过递归过程生成路径。然后，一旦用户做出选择，我便会通过ID将P与它在内存中的现有对象进行匹配。
或
（b）根据内存中已有的数据创建P的平面（无层次结构）列表，然后进行搜索，并使用常规代码生成路径。

要考虑的一些事情：
只会有十几个S，甚至可能有100-200 P s。
如果多人同时使用该程序，我不太在意内存中的数据是否会过时。
如果使用选项b，我可以创建P的平面列表并在程序加载时（在进行任何搜索之前）在后台线程上预先生成路径。
SQL Server可能正在网络上运行，因此应考虑那里的延迟。
如果SQL Server和运行该程序的计算机不在同一台计算机上，则它们的速度可能相当。

所以我想这里的主要问题是：
是否有任何原因（性能，最佳实践，可维护性等），我应该查询SQL Server，而不要使用内存中已有的数据？