如何使用Boost.MultiIndex为员工的多个向量字段建立索引？

背景 #

最初我们有如下Employee类，需要为hobbies向量字段建立索引：

class Employee {
  ...
  std::vector<std::string> hobbies;
};

当时采用的推荐方案是创建扁平结构，将每个爱好与员工关联，再基于该结构建立索引：

struct EmployeeWithHobby {
    Employee employee;
    std::string hobby;
};

typedef boost::multi_index::multi_index_container<
      EmployeeWithHobby,
      boost::multi_index::indexed_by<
          boost::multi_index::hashed_non_unique<
              boost::multi_index::tag<ByHobby>,
              boost::multi_index::member<
                  EmployeeWithHobby, std::string,
                  &EmployeeWithHobby::hobby>>>> index;

该方案运行正常，但现在Employee类新增了skills向量字段：

class Employee {
  ...
  std::vector<std::string> hobbies;
  std::vector<std::string> skills;
};

需要同时为hobbies和skills建立索引，以下是几种候选方案的分析：

方案1：创建独立的结构体与索引 #

分别为每个向量字段定义专属的扁平结构和索引：

struct EmployeeWithSkill {
    Employee employee;
    std::string skill;
};

// 爱好索引（复用原定义）
typedef boost::multi_index::multi_index_container<
      EmployeeWithHobby,
      boost::multi_index::indexed_by<
          boost::multi_index::hashed_non_unique<
              boost::multi_index::tag<ByHobby>,
              boost::multi_index::member<
                  EmployeeWithHobby, std::string,
                  &EmployeeWithHobby::hobby>>>> HobbyIndex;

// 技能索引
typedef boost::multi_index::multi_index_container<
      EmployeeWithSkill,
      boost::multi_index::indexed_by<
          boost::multi_index::hashed_non_unique<
              boost::multi_index::tag<BySkill>,
              boost::multi_index::member<
                  EmployeeWithSkill, std::string,
                  &EmployeeWithSkill::skill>>>> SkillIndex;

优缺点：

• 优点：逻辑清晰，每个索引仅对应一个向量字段，插入量为O(N+M)（N为爱好数量，M为技能数量），新增字段时只需添加新的结构体和索引，无需修改现有逻辑。
• 缺点：需要维护多个独立的multi_index_container，查询员工的所有关联信息时可能需要跨容器匹配。

方案2：合并字段到单一结构体（无std::optional） #

将爱好和技能字段合并到同一个扁平结构中：

struct EmployeeWithHobbyAndSkill {
    Employee employee;
    std::string hobby;
    std::string skill;
};

优缺点：

• 致命缺点：插入时需要生成爱好与技能的笛卡尔积，插入量变为O(N*M)。若后续新增更多向量字段（如interests），插入量会指数级增长（O(N*M*K)），完全无法维护，直接排除该方案。

方案3：用std::optional合并结构体 #

通过std::optional标记字段是否有效，避免笛卡尔积：

struct EmployeeWithHobbyOrSkill {
    Employee employee;
    std::optional<std::string> hobby;
    std::optional<std::string> skill;
};

typedef boost::multi_index::multi_index_container<
      EmployeeWithHobbyOrSkill,
      boost::multi_index::indexed_by<
          // 爱好索引：仅索引hobby有值的条目
          boost::multi_index::hashed_non_unique<
              boost::multi_index::tag<ByHobby>,
              boost::multi_index::member<
                  EmployeeWithHobbyOrSkill, std::optional<std::string>,
                  &EmployeeWithHobbyOrSkill::hobby>,
              // 自定义哈希函数，忽略nullopt
              [](const std::optional<std::string>& opt) {
                  return opt ? std::hash<std::string>{}(*opt) : 0;
              }>,
          // 技能索引：仅索引skill有值的条目
          boost::multi_index::hashed_non_unique<
              boost::multi_index::tag<BySkill>,
              boost::multi_index::member<
                  EmployeeWithHobbyOrSkill, std::optional<std::string>,
                  &EmployeeWithHobbyOrSkill::skill>,
              [](const std::optional<std::string>& opt) {
                  return opt ? std::hash<std::string>{}(*opt) : 0;
              }>>> CombinedIndex;

插入时，为每个爱好创建一条skill为nullopt的记录，为每个技能创建一条hobby为nullopt的记录，插入量控制在O(N+M)。

优缺点：

• 优点：所有索引集中在一个容器内，便于统一管理，插入量不会随字段数量增长而爆炸。
• 缺点：需要处理optional的空值逻辑，索引定义时要添加自定义哈希或过滤规则，代码复杂度略高于方案1。

推荐选择 #

• 若追求逻辑简洁、维护成本低，优先选方案1，每个向量字段独立管理索引，适合字段数量较少或查询逻辑相对独立的场景。
• 若希望所有索引统一在一个容器中，减少容器维护成本，可选择方案3，但需注意optional的空值处理逻辑。

内容的提问来源于stack exchange，提问作者Konstantin Milyutin