
CouchDB Book Now Available from O'Reilly - _pius
http://oreilly.com/catalog/9780596155902
======
Maro
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.

~~~
mrkurt
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
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.

------
dantheman
You can read the book here: <http://books.couchdb.org/relax/>

I was read the first few chapters as it was being written and thought it was
great.

------
knv
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.

------
dzlobin
Someone needs to write a MongoDB book already

~~~
mark_l_watson
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
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!

------
zacharypinter
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
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.

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

