couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Stott <>
Subject Re: starting with couchdb, few general questions
Date Sat, 04 Jul 2009 20:10:59 GMT
Pawel, it being the 4th of July, I don't have that much time on the comp,
but I'll try to get you going in the right direction.
A good approach would be to put a doc_type field on your documents.  You
could fill this in with 'professor', 'student', 'course', 'course_grade',
'enrollement'.  Enrollment docs would store a student id and a course id.
 You could create a view to find out what students were enrolled in what
classes that looked something like this:

function(doc) {
  if (doc.doc_type == "student") {
    emit([doc["_id"], 0], doc);
  } else if (doc.doc_type == "enrollment") {
    emit([doc.student_id, 1], doc);

You would then get output of student docs followed by the enrollment docs
that are associated with them.  Views are ordered, which is the point of the
combination key with 0 for student and 1 for the enrollment docs.

I suggest you read this article:

<>It'll give you a good
idea of the differences between couchdb and relational models and how to
handle "joins."

Got to get ready to eat too much to celebrate the independence of my
country.  Hope this was helpful :).

2009/7/3 paweł kamiński <>

> thanks for replay, If I can take some of your time
>> When your data is schemaless it's better to use a schemaless DB.
> as I can see more or less all examples are about storing html content so I
> can agree probably cDB suits better here.
>> If your data would normally be stored in a document
> ok, what is a document then. I think I miss a point here, lets take a
> classic situation like a university which has its student and professors and
> some administration,  so usually I would create one a table *
> people* (id_ppl, name, sex, address, phone, email, pict) that holds all of
> them.
> they all run classes or attend some courses or do other stuff I should
> create additional tables to hold specific information - *students*(id_std,
> date_start, date_graduate), *professors*(id_prf, title, room), *courses*(id_crs,
> id_prf, date_start, date_end, descr, type, points), *grades*(id_grd,
> id_prf, id_std, id_crs, mark) and so on I can join them by creating *
> classes*(id_crs, id_std)..
> (I hope it all make sens :) I have small fever so I can spend my friday
> evening in front of my computer:) anyway....
> *ok now migrating to cDB documents*
> universities/JagiellonianUniversity/people/ and here I put all information
> about people I want to manage; I think I could even do someting like that
> universities/JagiellonianUniversity/people/students    ->(id_ppl, name,
> sex, address, phone, email, pict, date_start, date_graduate)
> universities/JagiellonianUniversity/people/professors ->(id_ppl, name, sex,
> address, phone, email, pict, title, room)
> universities/JagiellonianUniversity/avaiblecourses/    ->(id_crs,
> date_start, date_end, descr, type, points)
> and so on (or please correct me here) but* how I create courese by teacher
> or by student*
> universities/JagiellonianUniversity/people/professors/professorName/courses
> ->(id_crs, date_start, date_end, descr, type, points)
> universities/JagiellonianUniversity/people/students/studentName/courses
> ->(id_crs, date_start, date_end, descr, type, points) ?????
> *how create document about students grades and how link them to professor
> and courses*
> universities/JagiellonianUniversity/people/students/grades/year/.... *have
> no idea, can I keep some reference to other documents*
> I think it is just me and I would like to know the idea how to model so
> simple example. (I hope I will but I need more time to go through all
> tutorials and articles on the wab...)
>> Validation is a part of couchdb.  You can write a validation function in
>> javascript to ensure data integrity.
> ufff :) hehe
> I'm sure as an old-sql developer you realize that if you write just any old
>> query, it's not going to perform well.  For example, querying by
>> non-indexed
>> columns is going to be a nightmare for performance.
> yes but usually you know what you are doing and you write statements that
> make sens. Ususally you join in a way that smalles subset of data are
> proccessed.
>> CouchDB views are indexed.  Check out the wiki for more info about how
>> couchdb views work.  Here's an intro to the views
> I will
>> Normalization is not something that document DBs concern themselves with.
>>  Often something you have multiple tables for will be one table in a
>> well-designed document DB.  Redundancy is often useful/necessary as well.
> I can agree take a look how SAS db stores data :) If performance is your
> first goal then it helps but on the other hand you dont deal with hundreds
> but dozens of tables. and your model is preatty simple and that is why you
> dont need to normalize that much, or am I wrong again?
> > 5)If my RDBS is running on 2core (ore sometimes one core) machine, and
>> that
>> > machine is alone server storing data from local clients is there any
>> gain
>> > of
>> > using systems such as couchDB or others (ok replication and other
>> features
>> > are still nice)
>> You'd have to benchmark your particular app to see if couchdb with a
>> well-thought-out schema out-performed your RDBMS.   For some tasks I'm
>> sure
>> it would.  For others, perhaps not.  If you're inserting a ton of
>> documents,
>> couchdb with its bulk insert would almost certainly outperform the RDBMS
>> from what I understand, though I do not have benchmarks to show this.
> I was asking more about erlangs nature of cdb, on one core machine or
> mobile it may not take advantage of multithreads. so I was wondering if it
> is worth to start playing with it if I target smaller, older machines. But
> YES let give it a try and then decide.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message