在设计像字典这样的东西时推荐的数据结构？

Question

TRIE是最值得推荐的数据结构，同时设计类似于存储单词的字典吗？是否有其他改善时间或内存性能的替代方案？

我相信如果没有碰撞，哈希可能会很好但是内存需求开始变得不好重叠的单词：覆盖，重叠，重叠，重叠，重叠都会占用独占存储，而我们可以在trie中共享空间。

编辑：感谢@Moron和大家提供的非常有用的答案。我同意 - 生成散列键是O（n），因此是TRIE搜索。然而，对于哈希事物可能会更糟糕，链接增加时间，而对于TRIE，这不会发生。我担心的是，对于TRIE中的每个节点，我需要保留一个指针，如果字典大小很小，它可能正在吹东西。

Answer 1

与哈希表相比，trie具有以下优势：

1. 与不完美的哈希表相比，查找特里结构中的数据在最坏的情况下O(m)时间更快。不完美的哈希表可能存在关键冲突。密钥冲突是将不同密钥的哈希函数映射到哈希表中的相同位置。不完美哈希表中的最差情况查找速度为O(N)时间，但更典型的是O(1)，评估哈希值的时间为O(m)。
2. trie中没有不同键的碰撞。
3. 只有当一个密钥与多个值相关联时，才需要存储类似于存储密钥冲突的哈希表存储桶的trie中的存储桶。
4. 不需要提供哈希函数或更改哈希函数，因为更多的键被添加到trie中。
5. 特里可以按键按字母顺序排列。

尝试有以下缺点：

1. 在某些情况下，尝试可能比查找数据的哈希表更慢，特别是如果数据直接在硬盘驱动器或其他辅助存储设备上访问，其中随机访问时间比主存储器高。
2. 将所有键表示为字符串并不容易，例如浮点数 - 使用其编码的位串直接编码会导致长链和前缀不是特别有意义。

如果缺点是你可以忍受的东西，我建议你去看看。

来源：Wikipedia: Trie#As a replacement of other data structures

Answer 2

您可以尝试考虑Directed Acyclic Word graph，这基本上是一个特里，但内存使用率更高，根据维基，对于英语，内存消耗远低于特里。

时间方面，它就像一个特里，可能比哈希更好。不知道你在哪里获得哈希的O（logn）时间。对于合理的哈希值应为O（n），其中n是被搜索词的长度。

Answer 3

我想这是个大问题，是吗？也许试试看Bloom过滤器？

http://en.wikipedia.org/wiki/Bloom_filter