|
Boost : |
From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-10-13 06:48:50
Hello Joe,
----- Mensaje original -----
De: Joe Gottman <jgottman_at_[hidden]>
Fecha: Jueves, Octubre 12, 2006 3:19 am
Asunto: [boost] [multi_index] Relationship Table
Para: boost_at_[hidden]
> One pattern that seems to come up pretty often is the
> relationship table.
> Suppose I have 2 classes, Employee and Skill. An Employee can
> have any number of Skills, and a Skill can be possessed by any
> number of Employees. But an Employee can have a given Skill
> only once. The user would need to be able to search for which
> Skills a given Employee has, and which Employees have a given
> Skill. What is the best way of using a multi_index_container
> to model this use case?
For instance, you can have the following (warning: uncompiled,
beware typos):
typedef std::pair<
boost::reference_wrapper<const Employee>,
boost::reference_wrapper<const Skill>
> EmployeeSkillPair;
typedef member<
EmployeeSkillPair,
EmployeeSkillPair::first_type,
&EmployeeSkillPair::first
> EmployeeExtractor;
typedef member<
EmployeeSkillPair,
EmployeeSkillPair::second_type,
&EmployeeSkillPair::second
> SkillExtractor;
multi_index_container<
EmployeeSkillPair,
indexed_by<
ordered_unique<
composite_key<
EmployeeSkillPair,
EmployeeExtractor,
SkillExtractor
>
>,
ordered_non_unique<
EmployeeExtractor
>
>
> EmployeeSkillRelations;
The first index enforces the uniqueness of a given
Employee-Skill link and lets you obtain the Skills
associated to an Employee (use equal_range passing
the Employee of interest --inside a tuple due to
the usage of composite keys, please consult the docs.)
The second index lets you retrieve the Employees
having a particular Skill.
> Suppose, in addition, that every Employee who has a Skill has
> a numerical rating at that Skill. How would you do a
> multi_index_container in that case?
Augment EmployeeSkillPair to store this rating too.
> Joe Gottman
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk