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.
