我目前有一项任务是使用选项符号，并使它们可以从缓存中轻松搜索，以便从基于Web和Windows的各种不同应用程序中快速查找。我们已经决定提供WFC服务以便为我们返回结果 缓存需要大约500k条记录。当我们这样做时，使用Trie对象我们的内存占用大约为400 MB。我被指示让那个更小。
在我们的世界ROOT:DATESTRING:PRICE:TYPE或IBM:130119:215.0:C
所以我在想，由于这里有大量的重复，我可以为每个部分构建一个Trie，当完成后，内存使用量大约为30 MB。
所以我现在的困境是如何将它们联系起来，所以它仍然是一个连续的Trie搜索。如果我做一个简单的父母孩子，我可能会得到错误的结果，因为价格的父母是日期，并且可能具有该ROOT或类型不会发生的价格。我们当前的方法是使用另一个对象，它是一个类似于数据库中的连接表的链接对象。我们为每个最终节点提供一个UniqueID，然后建立适当的关系。这仍然非常快，并且不会占用大量内存，但我想知道其他人可能会建议以更有效的方式链接这些项目。
其他信息： 因此，我当前实现中的选项符号的每个部分都是它自己的Trie。 所以，如果我有以下选项： IBM：130119：215.0：C APPL：130119：215.0：C APPL：130119：600.0：C 答：130119：31：0：C IBM：130119：220.0：C IBM：130119：215.0：P 我随后会为根构建一个trie：作为我的节点结构的一部分，有一个结束值可以知道我到底在哪里。
root Date Price OptType
/ \ | / \ \ / \
A I 1 2 3 6 P C
/ \ | | / \ | |
A B 3 2 1 1 0
| | | | | | |
P M 0 0 5 . 0
| | | | | |
L 1 . . 0 .
| | | | |
1 0 0 0 0
|
9
因此，如果没有办法链接其中的每一个，我可以通过使用Parent Child获得许多误报。由于日期的孩子是价格。 我曾考虑将所有父子片段放在Root上，使其成为一种特殊类型的NODE，以便不为那些不需要的其他人提供一堆空数据。但是我们确定了一个链接表，但是根本不能正常工作。我没有说这是正确的实现，但我们确实需要CACHE所有这些记录，因为它们的调用次数和频率。