I have been trying to ascertain if I'm able to accomplish some needs having a document based database, within this situation CouchDB. Two generic needs:
- CRUD of organizations with a few fields that have unique index onto it
- ecommerce web application like eBay (better description here).
And I am begining to consider that the Document-based database is not the best option to deal with these needs. In addition, I can´t make a use for any Document based database (maybe my imagination is simply too little).
Are you able to explain me if I'm asking pears for an elm after i use a Document based database with this needs?
You have to think about the way you approach the applying within an Document oriented way. Should you simply try to replicate the way you would model the issue within an RDBMS you'll fail. You will find also different trade-offs that you desire to create. Remember too that CouchDB's design is presuming that you may have an energetic active cluster of numerous nodes that may fail anytime. How's your application likely to handle among the database nodes dissapearing from under it?
One method to consider it's to assume you did not have computer systems, just paper documents. How does one create a competent business process using items of paper being passed around? How will you avoid bottlenecks? What if something wrong happens?
Another position you need to consider is eventual consistency, where you're going to get right into a consistent condition eventually, however, you might be sporadic for many time period. It is really an anathema in RMDBS land, but is very common within the real life. The canonical transaction example is of moving money from accounts. So how exactly does this really take place in the real life? Via a single atomic transactions or through different banks giving credit and debit notices to one another? What goes on whenever you write an inspection?
So allows review your good examples:
- CRUD of organizations with a few fields with unique index onto it.
Basically appreciate this properly in CouchDB terms, you need to have an accumulation of documents where some that some named value is certain to be unique across all individuals documents? That situation is not generally supportable because documents might be produced on different replicas.
So we have to consider the real life problem and find out as we can model that. Do you require these to be unique? Can the application handle multiple paperwork with similar value? Must you assign a distinctive identifier? Can you accomplish that deterministically? A typical scenario where this really is needed is to require a unique consecutive identifier. This really is difficult to solve inside a duplicated atmosphere. Actually when the unique id is have to be strictly consecutive regarding time produced no one is able if you want the id immediately. You have to relax a minumum of one of individuals constraints.
- ecommerce web application like ebay
I am unsure things to add because the final comment you've made on that publish ended up being to say "very helpful! thanks". Was there something missing in the approach layed out there that's still leading to a problem? I figured MrKurt's answer was pretty full and that i added just a little enhancement that will reduce contention.
It is possible to have to normalize the information?
- Yes: Use relational.
- No: Use document.
Document based DBs would be best meeting for storing, well, documents. Lotus Notes is a very common implementation and Notes email is definitely an example. For what you're explaining, eCommerce, CRUD, etc., realtional DBs are better created for storage and retrieval of information products/elements which are indexed (instead of documents).