all that said, I think there really is a benefit to document dbs: maybe you don't care about second order applications yet.
If you don't care about second order applications yet, then you don't have anybody asking questions about what's happening in the business yet. Make sure you're equipped to answer these questions, whether via relational queries or map-reduce jobs or whatever. Also make sure that you can turn around requests for a lot of different kinds of these queries, both scheduled and ad-hoc. Business folks call this "reporting" and it isn't optional, because it's one of the business' main ways of staying grounded in reality. Is the new marketing campaign working? Are the demographics of our users match our predictions? How did last week's outage affect customer retention? The worst case scenario is when the answers to those questions are nonexistent, and the second worst case is if they're hidden in log files, but after those two the worst case scenario is if the only people who can write queries against your datastore to answer those questions are the hard-core developers who ought to be adding new features or working on infrastructure.
So however you store your data, make sure it isn't rocket science to write the queries that the business guys need to answer their questions. Otherwise your rocket scientists will be wasted answering marketing questions like, "How many iPhone users who purchased our service in February used it in both March and April?" instead of improving your technology.
P.S. I believe reporting is a major motivation behind the SQL-like languages that pop up for non-relational databases, but my experience with the problem I described was actually with a very large and complicated relational database, so SQL is no panacea. It took us a long time to create a reporting team that was self-sufficient enough to shield our senior database developers from the flow of menial reporting work.
Comments
all that said, I think there really is a benefit to document dbs: maybe you don't care about second order applications yet.
If you don't care about second order applications yet, then you don't have anybody asking questions about what's happening in the business yet. Make sure you're equipped to answer these questions, whether via relational queries or map-reduce jobs or whatever. Also make sure that you can turn around requests for a lot of different kinds of these queries, both scheduled and ad-hoc. Business folks call this "reporting" and it isn't optional, because it's one of the business' main ways of staying grounded in reality. Is the new marketing campaign working? Are the demographics of our users match our predictions? How did last week's outage affect customer retention? The worst case scenario is when the answers to those questions are nonexistent, and the second worst case is if they're hidden in log files, but after those two the worst case scenario is if the only people who can write queries against your datastore to answer those questions are the hard-core developers who ought to be adding new features or working on infrastructure.
So however you store your data, make sure it isn't rocket science to write the queries that the business guys need to answer their questions. Otherwise your rocket scientists will be wasted answering marketing questions like, "How many iPhone users who purchased our service in February used it in both March and April?" instead of improving your technology.
P.S. I believe reporting is a major motivation behind the SQL-like languages that pop up for non-relational databases, but my experience with the problem I described was actually with a very large and complicated relational database, so SQL is no panacea. It took us a long time to create a reporting team that was self-sufficient enough to shield our senior database developers from the flow of menial reporting work.