The reason for my first suggestion was to make it easy to get a particular course knowing its subject, term and number.
If you have other fields by which you'd like to search or order documents you would use a view and carefully choose your view keys according to the collation rules I linked. The collation rules are Couch's implicit equivalent of ORDER BY. For example, you could have a view courses_by_type. It would emit(doc.type, ...), which would give you a view of all courses ordered by type. Or emit([doc.type,...], ...) will still give you a list ordered by type, but also further organized within the type by any other fields you want to add to the key. Reductions are typically for aggregation. It is discouraged and couch will by default prevent you from making reduce functions which do not reduce the output. In other words, building a giant list with reduce is a bad idea. Performance would suffer. If you're looking for some more powerful ways to view your data you should also check out list and show functions. See: http://wiki.apache.org/couchdb/Formatting_with_Show_and_List http://guide.couchdb.org/editions/1/en/formats.html http://guide.couchdb.org/editions/1/en/lists.html Good luck. Randall On Wed, Aug 25, 2010 at 19:26, matt hebel <[email protected]> wrote: > Thanks that does help, I think I will try your first suggestion. One other > thing if i wanted to reduce it based on another value is it possible? Say it > returns a big list of COMPSCI:A:1011 but i only want the type LEC could i > use reduce for that? > > Also I might want only to get out specific type slots would I use reduce for > that. or is reduce only meant for aggregates ? > > > > On Wed, Aug 25, 2010 at 10:04 PM, Randall Leeds > <[email protected]>wrote: > >> You have two options: >> Since these combination of things uniquely identifies a course you >> could set the _id field explicitly to something like >> subject:term:course_code. Choose whatever separator you need or encode >> the parts such that you can be sure you can always make sense of it. >> >> The option option is to add a view to a design document which emits >> [subject, term, course_code]. >> Depending on the sorts of queries you want to do you should choose an >> ordering of these terms such that you can answer as many of your >> queries as possible with simple range requests. >> >> See http://wiki.apache.org/couchdb/View_collation for more information. >> >> Hope that helps! >> Randall >> >> On Wed, Aug 25, 2010 at 18:54, matt hebel <[email protected]> wrote: >> > Hello, my data is kind of unique and it will work best if i use couchDB >> to >> > store and retrieve the data but I'm having a hard time getting out what I >> > need. >> > >> > a document looks like this. >> > >> > { >> > "_id": "7d33b72f256fae4615dcea99cd7a2239", >> > "_rev": "1-587b7a9811db08f8abf925bc44a23bb9", >> > "term": "A", >> > "course_code": "1011", >> > "course_title": "Internet: Behind the Curtain", >> > "subject": "COMPSCI", >> > "section": "002", >> > "type": "LEC", >> > "class_number": 31912, >> > "building_room": "MC-105B", >> > "Instructor": "Andrews", >> > "full": false, >> > "time": [ >> > { >> > "day": "W", >> > "start": 1230, >> > "end": 1330 >> > }, >> > { >> > "day": "T", >> > "start": 1230, >> > "end": 1330 >> > } >> > ], >> > "days": { >> > "M": { >> > "s": 1230, >> > "e": 1330 >> > }, >> > "Tu": { >> > }, >> > "W": { >> > "s": 1430, >> > "e": 1530 >> > }, >> > "Thu": { >> > }, >> > "F": { >> > } >> > } >> > } >> > >> > >> > Where I'm having problems is getting out the sections that belong >> together. >> > I need to know that its from subject, term,course_code. If that data is >> not >> > provided i will end up with a mess of data that do not relate because >> there >> > are courses with course code 1011 in other subjects. Therefor make it >> unique >> > i need the subject, term, and course code. >> > >> > Should i design my documents differently? >> > >> > or how should i retrieve this data? >> > >> > >> > Matt >> > >> >
