因此，如果我必须在哈希表或前缀树之间进行选择，那么导致我选择其中一个的区别因素是什么。从我自己幼稚的角度来看，似乎使用 trie 有一些额外的开销，因为它没有存储为数组，但就运行时间而言（假设最长的键是最长的英文单词）它本质上可以是 O (1) (关于上限)。也许最长的英文单词是50个字符？
哈希表是即时查找一旦你得到索引。然而，散列密钥以获取索引似乎很容易花费近 50 步。
有人可以为我提供一个更有经验的观点吗？谢谢！
【问题讨论】：
00110010 可能是输入字节，但您希望包含匹配的 00111010，它只删除了一位。
标签： algorithm data-structures hashtable trie
尝试的优点：
基础知识：
新操作：
链接结构的优点：
哈希表的优点：
【讨论】：
这完全取决于您要解决的问题。如果您需要做的只是插入和查找，请使用哈希表。如果您需要解决更复杂的问题，例如前缀相关的查询，那么 trie 可能是更好的解决方案。
【讨论】：
每个人都知道哈希表及其用途，但它并不完全是恒定的查找时间，它取决于哈希表有多大，哈希函数的计算复杂度。
在大多数工业场景中，即使是很小的延迟/可扩展性也很重要（例如：高频交易），为高效查找创建巨大的哈希表并不是一个优雅的解决方案。您还必须关心要针对其在内存中占用的空间进行优化的数据结构，以减少缓存未命中。
trie 更适合需求的一个很好的例子是消息中间件。您有一百万个不同类别的消息订阅者和发布者（在 JMS 术语中 - 主题或交换），在这种情况下，如果您想根据主题（实际上是字符串）过滤掉消息，您肯定不想创建哈希表拥有百万主题的百万订阅。更好的方法是将主题存储在 trie 中，因此当基于主题匹配进行过滤时，其复杂性与主题/订阅/发布者的数量无关（仅取决于字符串的长度）。我喜欢它，因为您可以创造性地使用这种数据结构来优化空间需求，从而降低缓存未命中率。
【讨论】：
使用一棵树：
【讨论】：
我没有看到任何人明确提及我认为需要牢记的重要内容。哈希表和各种尝试通常都有O(k) 操作，其中k 是字符串的长度，以位为单位（或等效地以字符为单位）。
这是假设你有一个好的散列函数。如果您不希望“农场”和“农场动物”散列到相同的值，那么散列函数将不得不使用密钥的所有位，因此散列“农场动物”大约需要两倍的时间“农场”（除非您处于某种滚动哈希场景中，但也有一些类似的操作保存场景与尝试）。使用香草树，很明显为什么插入“农场动物”所需的时间大约是“农场”的两倍。从长远来看，压缩尝试也是如此。
【讨论】：
在 trie 上的插入和查找与输入字符串 O(s) 的长度呈线性关系。
散列会给你一个 O(1) 的查找和插入，但首先你必须根据输入字符串计算散列，这也是 O(s)。
结论，渐近时间复杂度在这两种情况下都是线性的。
从数据的角度来看，trie 有更多开销，但您可以选择一个压缩的 trie，它会让您再次或多或少地与哈希表平起平坐。
要打破平局，请问自己这个问题：我只需要查找完整的单词吗？还是我需要返回与前缀匹配的所有单词？ （如在预测文本输入系统中）。对于第一种情况，请使用哈希。它是更简单、更干净的代码。更容易测试和维护。对于前缀或后缀很重要的更详细的用例，请尝试一下。
如果您只是为了好玩而这样做，那么实施 trie 可以很好地利用周日下午。
【讨论】：
HashTable 实现更节省空间。但是对于字符串，在大多数实际应用中都需要排序。但是 HashTable 完全打乱了字典顺序。现在，如果您的应用程序正在执行基于字典顺序的操作（如部分搜索、所有具有给定前缀的字符串、所有单词按排序顺序），您应该使用 Tries。仅用于查找，应使用 HashTable（可以说，它提供了最短的查找时间）。
P.S.：除此之外，三元搜索树 (TST) 将是一个很好的选择。它的查找时间比 HashTable 长，但在所有其他操作中都具有时间效率。此外，它比尝试更节省空间。
【讨论】：
一些（通常是嵌入式的、实时的）应用程序要求处理时间独立于数据。在这种情况下，哈希表可以保证已知的执行时间，而 trie 会根据数据而变化。
【讨论】：