Many-to-many views sorted and paginated

[Zoltan Lajos Kis <ki...@tmit.bme.hu>]

Hello all,

Could you please help me with a design question?

I would like to have an application with users and events (each having 
its own document type), where a user can register for any of the events. 
Each user should be able to see the list of events he/she registered 
for, sorted by time or location (selectable), with pagination.

I understand that if I stored registration data within event documents, 
e.g. by listing userid's, this would be as simple as emitting keys like
[event.registered[i], event.date, event.location] and then querying with 
"?startkey=[userid]&endkey=[userid, {}]&limit=20"

However, for me it seems more appropriate from several aspects not to 
store the registration data within the event documents. I would rather 
store them along with user data. I came up with a possible solution for 
this arrangement, which requires three consecutive requests to couchdb:

1. Using a view, which emits ( [event.date, event.location], event.id ), 
I get the list of all eventid's, properly sorted (without the documents).

2. I retrieve the id's of the events the user has registered for from 
the appropriate user document. Then on the "client side" I filter the 
list of eventid's,
keeping only those that are relevant. Then I keep only those that are 
needed for the current page viewed.

3. Using the multi-document-fetch feature I retrieve all event documents 
by posting the list of remaining eventid's. As the id's were sorted, the 
documents will be returned in a sorted order as well.

So my question is: is there any other solution that I am not aware of, 
that can achieve the same result with less requests? Is three requests 
too much, anyway? Also, is this solution viable with the fact that it 
retrieves the id of all events from the database?

Thank you.

Kindest Regards,
Zoltan.

Re: Many-to-many views sorted and paginated

[Maciej Dziardziel <ma...@wp.pl>]

Zoltan Lajos Kis wrote:

> I understand that if I stored registration data within event documents,
> e.g. by listing userid's, this would be as simple as emitting keys like
> [event.registered[i], event.date, event.location] and then querying with
> "?startkey=[userid]&endkey=[userid, {}]&limit=20"
> 
> However, for me it seems more appropriate from several aspects not to
> store the registration data within the event documents.

You could store those data in both places.


> 1. Using a view, which emits ( [event.date, event.location], event.id ),
> I get the list of all eventid's, properly sorted (without the documents).

Depending on the number of events this can kill your perfomance - 
downloading large amount of data (reading them first from disk)
looks for me like worst possible solution.



-- 
Maciej "Fiedzia" Dziardziel