4 ms·

CouchDB Book Now Available from O'Reilly

40 points by _pius 17y ago

dantheman 17y ago
You can read the book here: http://books.couchdb.org/relax/ http://books.couchdb.org/relax/ I was read the first few chapters as it was being written and thought it was great.
zacharypinter 17y ago
If I recall correctly, the original title was "Relax with CouchDB". It looks like the relax line is now a sub-sub-title ("Time to Relax"). Anybody know the backstory of the title change? Did O'Reilly push for it?
- javery 17y ago
  It looks like they put it in the Definitive Guide series which then has some strong requirements around the brand and most likely was the cause of the name change. It's probably a good thing for the authors as it is a respected series and will probably result in more sales.
- bitdiddle 17y ago
  Interesting, I always recall the title was CouchDB: "The Definitive Guide". Perhaps I forgot this earlier title
Maro 17y ago
I'm sure CouchDB is great, but this book, at least the first part, is really bad, full of half-truths and sometimes just plain wrong. I'm amazed O'Reilly is publishing this. Is there no editor involved to catch these mistakes? In the section "Self-Contained Data" the author makes the argument that some data is better stored as a document than a bunch of relations, and uses INVOICES as an example: "Accountants appreciate the simplicity of having everything in one place. And given the choice, programmers appreciate that, too.". Invoices (and other business data) are the classical example of something that belongs in an RDBMS and not in something like CouchDB. It's not that hard to come up with a good examples for "relaxed data", like... say... blog posts, or blog comments, or twitter messages, or search results, or log entries? Later, it gives incorrect/meaningless definitions for Consisteny, Availability and Partition Tolerance. It then completely confuses the CAP theorem, incorrectly placing Paxos (puts in under CA, should be CP). It also places RDMBSs on the figure, which is silly, "Relational Database Management System" in itself says nothing about how it is distributed, if even. Part I/1+2 needs major rewriting.
- BjornW 17y ago
  You might have missed it, but the authors encourage you to contact them and give them feedback. It is probably to late for the written/published book by O'Reilly, but perhaps your feedback will be used to alter the online version. You might want to give it a try and let them know?
  - Maro 17y ago
    This seems to be a publised O'Reilly book. If I want to get maybe-good-maybe-not-so-good info I read blogs, not pay money for a book. This book should be a blog. It's not worth money.
- mrkurt 17y ago
  Invoices seem like a pretty good candidate for a document DB to me. It's much, much easier to store a list of "line items" in a single document than it is to extract those out into a properly normalized structure. What advantage does having that data across multiple tables give you? Blog comments, on the other hand, might benefit from more normalization. Cramming a bunch of comments into a post document could result in contention problems, depending on the engine and how you're handling them. In CouchDB, you'd end up having to update the entire post document for each new/changed comment. Mongo handles it better, since you can atomically push new comments into your doc. Still, I think I'd rather have them in their own documents on a busy site.
  - systems 17y ago
    The Key benefit of Relational Databases is to maintain integrity. And they do this primarily via 2 concepts: (1) Normalization: storing each fact in the db once (2) Referential Integrity. In an Invoices you have an Invoice Header, that should refer to multiple entities, buyer, seller, shipment address etc ... . Invoice detail that refer to the Header and represent a one to many relation between the data in the invoice header and the items in the invoice. Which may also have additional relationship attributes, like price, discount or any details specific to the item, for example, maybe your DB support a shipment address per item! Anyway, in a relation DB an invoice refer to many entities (separate facts) and many relations (also separate facts) each worthy of its own table that refer to each other. If you believe that Invoices are a good candidate for a document DB, you probably don't believe that the Relational Model is valid in general. Or that the 2 concepts I mentioned at first really help integrity! The main flaw I see is that the relational model makes is hard to create dynamic models. A good Relational Model practice is that an entity in a Relational DB should represent an entity from your Universe Of Discourse (uod). That is the say, a model is better when tables represent real entities of the problem you are modelling! This is sometimes impossible when you want to store dynamic structures, some argue that this is not the fault of the Relational Model theory, but rather its implementations.
dzlobin 17y ago
Someone needs to write a MongoDB book already
- mark_l_watson 17y ago
  Yes, but MongoDB is so easy to use, at least with Ruby and the mongo and mongo_record gems, that it would be a very short book. BTW, I just wrote a 3 part article for developer.com that has CouchDB and MongoDB examples.
  - dzlobin 17y ago
    True but there is surely a lot of use cases and interesting advanced uses that could make for an interesting book. And I'll check your articles out!
cturner 17y ago
Thanks for the tip. You saved me from having my standing amazon order ship to a former workplace on an inconvenient continent.
knv 17y ago
Judging by online version calling this book a definitive guide is somehow misleading. There are still many crucial details about CouchDB that you cannot find in this book and you have to search for them in mailing lists/blogs/wikis. I think a title like Starting Couchdb with Couchapp fits better for this book.

40 points by _pius 17y ago

You can read the book here: http://books.couchdb.org/relax/ http://books.couchdb.org/relax/ I was read the first few chapters as it was being written and thought it was great.

zacharypinter 17y ago

If I recall correctly, the original title was "Relax with CouchDB". It looks like the relax line is now a sub-sub-title ("Time to Relax"). Anybody know the backstory of the title change? Did O'Reilly push for it?

javery 17y ago
It looks like they put it in the Definitive Guide series which then has some strong requirements around the brand and most likely was the cause of the name change. It's probably a good thing for the authors as it is a respected series and will probably result in more sales.
bitdiddle 17y ago
Interesting, I always recall the title was CouchDB: "The Definitive Guide". Perhaps I forgot this earlier title

Maro 17y ago

I'm sure CouchDB is great, but this book, at least the first part, is really bad, full of half-truths and sometimes just plain wrong. I'm amazed O'Reilly is publishing this. Is there no editor involved to catch these mistakes? In the section "Self-Contained Data" the author makes the argument that some data is better stored as a document than a bunch of relations, and uses INVOICES as an example: "Accountants appreciate the simplicity of having everything in one place. And given the choice, programmers appreciate that, too.". Invoices (and other business data) are the classical example of something that belongs in an RDBMS and not in something like CouchDB. It's not that hard to come up with a good examples for "relaxed data", like... say... blog posts, or blog comments, or twitter messages, or search results, or log entries? Later, it gives incorrect/meaningless definitions for Consisteny, Availability and Partition Tolerance. It then completely confuses the CAP theorem, incorrectly placing Paxos (puts in under CA, should be CP). It also places RDMBSs on the figure, which is silly, "Relational Database Management System" in itself says nothing about how it is distributed, if even. Part I/1+2 needs major rewriting.

BjornW 17y ago
You might have missed it, but the authors encourage you to contact them and give them feedback. It is probably to late for the written/published book by O'Reilly, but perhaps your feedback will be used to alter the online version. You might want to give it a try and let them know?
- Maro 17y ago
  This seems to be a publised O'Reilly book. If I want to get maybe-good-maybe-not-so-good info I read blogs, not pay money for a book. This book should be a blog. It's not worth money.
mrkurt 17y ago
Invoices seem like a pretty good candidate for a document DB to me. It's much, much easier to store a list of "line items" in a single document than it is to extract those out into a properly normalized structure. What advantage does having that data across multiple tables give you? Blog comments, on the other hand, might benefit from more normalization. Cramming a bunch of comments into a post document could result in contention problems, depending on the engine and how you're handling them. In CouchDB, you'd end up having to update the entire post document for each new/changed comment. Mongo handles it better, since you can atomically push new comments into your doc. Still, I think I'd rather have them in their own documents on a busy site.
- systems 17y ago
  The Key benefit of Relational Databases is to maintain integrity. And they do this primarily via 2 concepts: (1) Normalization: storing each fact in the db once (2) Referential Integrity. In an Invoices you have an Invoice Header, that should refer to multiple entities, buyer, seller, shipment address etc ... . Invoice detail that refer to the Header and represent a one to many relation between the data in the invoice header and the items in the invoice. Which may also have additional relationship attributes, like price, discount or any details specific to the item, for example, maybe your DB support a shipment address per item! Anyway, in a relation DB an invoice refer to many entities (separate facts) and many relations (also separate facts) each worthy of its own table that refer to each other. If you believe that Invoices are a good candidate for a document DB, you probably don't believe that the Relational Model is valid in general. Or that the 2 concepts I mentioned at first really help integrity! The main flaw I see is that the relational model makes is hard to create dynamic models. A good Relational Model practice is that an entity in a Relational DB should represent an entity from your Universe Of Discourse (uod). That is the say, a model is better when tables represent real entities of the problem you are modelling! This is sometimes impossible when you want to store dynamic structures, some argue that this is not the fault of the Relational Model theory, but rather its implementations.

dzlobin 17y ago

Someone needs to write a MongoDB book already

mark_l_watson 17y ago
Yes, but MongoDB is so easy to use, at least with Ruby and the mongo and mongo_record gems, that it would be a very short book. BTW, I just wrote a 3 part article for developer.com that has CouchDB and MongoDB examples.
- dzlobin 17y ago
  True but there is surely a lot of use cases and interesting advanced uses that could make for an interesting book. And I'll check your articles out!

cturner 17y ago

Thanks for the tip. You saved me from having my standing amazon order ship to a former workplace on an inconvenient continent.

knv 17y ago

Judging by online version calling this book a definitive guide is somehow misleading. There are still many crucial details about CouchDB that you cannot find in this book and you have to search for them in mailing lists/blogs/wikis. I think a title like Starting Couchdb with Couchapp fits better for this book.