Probably the best example of GPO performance and scalability is in the mechanism to represent associations.

One To Many

A one-to-many set is represented by many objects all referencing a single object with the same property key.

This defines a linked structure that runs from the target object and through all the members.

In a relational database this is the equivalent to indexing a column in a table, but in GPO it is more direct.

As the set grows, the linked structure always requires the same number of updates to be made for each new entry - no matter whether the set consists of ten or ten million objects.

Many To Many

The utility GPO class ManyManyLink is used to manage these associations - although there is no reason why other GPO objects could not be used in logically the same way.

The main advantage of the ManyManyLink is that it utilizes the alternative GPO constructor to store itself along with one of the two objects it links together.

Logically it does not matter where the link object resides, but it chooses to live with the one with the smaller set. This balances out the storage requirements of the GPO objects.

It should be clear that this means that although an intermediate object is used to represent a link between two objects, it must always be loaded along with one of the two objects.

Thus the many-to-many overhead is simply a small increase in size of each of the objects rather than the separate table and indexing requirements of a relational join table. It can further be demonstrated that the processing cost of iterating a many-to-many set is equivalent to iterating a one-to-many set of similar size.