couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Trivial Update of "EntityRelationship" by Adam Wolff
Date Wed, 29 Apr 2009 20:39:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by Adam Wolff:
http://wiki.apache.org/couchdb/EntityRelationship

------------------------------------------------------------------------------
  For the most efficient changes to the relationship list, you should place the list on side
of the relationship which you expect to have fewer values. In the example above, the Contact
side was chosen because a single person is not likely to belong to too many groups, whereas
in a large contacts database, a group might contain hundreds of members.
  
  ==== Querying by multiple keys ====
- Some applications need to view the union of entities that have multiple keys. In the example
above, this would be a query for the contacts who are in both the "Friends" and the "Colleagues"
groups. The most straight-forward way to handle this situation is to query for one of the
keys, and then to filter by the rest of the keys on the client-side. If the key frequencies
vary greatly, it may also be worthwhile to make an initial call to determine the key with
the lowest frequency, and to use that to fetch the initial document list from the database.
+ Some applications need to view the intersection of entities that have multiple keys. In
the example above, this would be a query for the contacts who are in both the "Friends" and
the "Colleagues" groups. The most straight-forward way to handle this situation is to query
for one of the keys, and then to filter by the rest of the keys on the client-side. If the
key frequencies vary greatly, it may also be worthwhile to make an initial call to determine
the key with the lowest frequency, and to use that to fetch the initial document list from
the database.
  
  If this is not a good option, it is possible to index the combinations of the keys, though
the growth of the index for a given document will be exponential with the number of its keys.
Still, for small-ish key sets, this is an option, since the keys can be ordered, and keys
which are prefixes of a larger key can be omitted. For instance, for the key set {{{[1 2 3]}}}
the possible key combinations are {{{[1] [2] [3] [1 2] [1 3] [2 3] [1 2 3]}}} However, the
index need only contain the keys {{{[3] [1 3] [2 3] [1 2 3]}}} since (for example) the documents
matching the keys [1 2] could be obtained with a query for {{{startkey=[1,2,null] and endkey=[1,2,{}]}}}
The number of index entries will be 2^(n-1) number of keys.
  

Mime
View raw message