我需要一些建议来选择排序算法来编码这个问题。
在第一阶段，程序将从数据库中获取clientID和各自的哈希值（可能会使用结构）。可以有0或数千条记录。
在第二阶段，程序将使用从XML文件读取的记录完成此设置。我已经构建了流解析器。 XML文件在发票数据之前按顺序包含所有客户信息。
完成第二阶段后，程序将读取发票数据。对于每张发票，都有一个clientID，必须从客户端集中检查。发票数量可以是数百万条记录。
我最初的想法。由于我不知道会有多少客户端记录，因此我必须使用链表动态添加内存。在第二阶段结束时，我可以创建一个由clientID排序的数据数组，这样我就可以快速检索每个发票中的一个搜索，也许可以使用二进制搜索。
我想知道你有什么建议我来处理这种情况。我应该使用哪种算法？ （我将用C编码。）
答案 0 :(得分：3)
可以说，最好的算法是满足以下标准的算法：
鉴于数千条记录基本上没有，我建议使用qsort进行排序，bsearch进行搜索;这两个都在C标准库中。
需要注意的问题：
qsort无法在链接列表中使用。我强烈建议将数据存储在动态增长的数组中;分摊的创建成本是相同的，您将获得其他好处（例如更少的内存开销，更好locality of reference）。
如果在仔细分析后发现bsearch速度不够快，那么您可能希望转到基于散列表的查找，因为这是O（1），而不是O（记录N）。但是，不要试图自己写;为此使用现有的库。 （请参阅此处的其他答案以获取建议。）
答案 1 :(得分：1)
glib library包含hash table implementation。虽然未排序，但hash tables会让您执行O（1）或constant-time lookups，如果您要查找数百万张发票，这将非常有用。
还有其他可能性，例如Client结构的排序数组，通过它可以执行binary search。假设您的Client结构包含一个名为unsigned int的{{1}}成员。如果您的客户端ID是唯一的monotonically increasing（不一定等于数组索引，但是增加），并且您有clientID条记录，那么您只需要转到数据透视索引n并查看您的感兴趣的ID floor(n/2)是否大于，等于或小于在枢轴索引处的结构引用所引用的ID，以便决定接下来要查看的数组的哪一半。您的新数据透视索引将是该子数组的下限和上限的中点，您可以递归搜索直到找到感兴趣的元素。
通过排序数组进行二进制搜索的查找性能是O（log n） - 比散列表慢，并且排序数组的成本非零，但总体内存开销可能更小。如果你有内存，哈希表可能会更快，因此通常是一个很好的结构，适用于大量的查找。