想象一下，您想序列化和反序列化 stackoverflow 帖子，包括它们的标签，尽可能有效地节省空间（以二进制形式），而且在进行标签查找时也能提高性能。这种场景有没有好的数据结构？
Stackoverflow 有大约 28532 个不同的标签，您可以创建一个包含所有标签的表格并为它们分配一个整数，此外您可以按频率对它们进行排序，以便最常见的标签具有最低的数字。从搜索和存储的角度来看，仍然像“1 32 45”格式的字符串一样简单地存储它们似乎有点低效
另一个想法是将标签保存为变量位数组，这从查找和序列化的角度来看很有吸引力。由于最常见的标签是第一个，因此您可能会将标签放入少量内存中。
问题当然是不常见的标签会产生巨大的位数组。是否有任何标准用于“压缩”大跨度 0 的位数组？还是应该完全使用其他结构？
编辑
我不是在寻找数据库解决方案或需要将整个表保存在内存中的解决方案，而是用于过滤单个项目的结构
不要破坏您的问题，但 28k 记录确实不是那么多。您是否可能过早优化？我会首先坚持在数据库表上使用“常规”索引。他们使用的苛刻的启发式方法通常非常有效并且不容易被击败（或者如果可以的话，是否真的值得及时努力并且收益足够大？）。
还取决于您实际执行标签查询的位置，用户是否真的注意到您优化的 200 毫秒时间增益？
首先测量然后优化:-)
编辑
如果没有数据库，我可能会有一个主表，将所有标签和一个 ID 一起保存（如果可能的话，将它保存在内存中）。与每个帖子一起保留一个定期排序的 ID 列表。
不确定基于通用性的存储量会有所帮助。可以在其中进行常规二进制搜索的排序列表可能证明足够快。措施 ：-）
在这里，您需要为每个标签查询迭代所有帖子。
如果这最终变慢，您可以诉诸为每个标签存储一个帖子标识符的口袋。这个数据结构可能会变得有点大，并且可能需要一个文件来查找和读取。
对于较小的表，您可以基于散列值（带有重复值）构建一个。通过这种方式，您可以使用它来快速找到需要进一步检查以查看它们是否匹配的较小的候选帖子列表。
您需要第二个包含 2 个字段的表：tag_id question_id
而已。然后，您在 tag_id、question_id 和 question_id、tag_id 上创建索引 - 这将覆盖索引，因此您的所有查询都会非常快。
我感觉你的问题抽象得太多了；你没有说太多你想如何访问数据结构，这很重要。
话虽如此，我建议计算每个标签的出现次数，然后使用霍夫曼编码来得出可用于标签的最短编码。这并不完全完美，但我会坚持下去，直到你证明它不合适。然后，您可以将代码与每个问题相关联。
如果您想有效地查找特定标签中的问题，您将需要某种索引。也许，所有的 Tag 对象都可以有一个引用数组（引用、指针、nummeric-id 等）到所有用这个特定标签标记的问题。这样，您只需要找到标签对象，并且您有一个指向该标签所有问题的数组。