I'm not convinced. Of course these projects are useful for some applications but most online services will never grow to the size where you HAVE to dump your SQL server for something more scalable. And in the meanwhile SQL is just sooo convenient and easy to develop on. Why would I want to switch unless I have to?
You'll still be able to use SQL. You will still use RDBMses for things they are good at. You will stop using SQL for things SQL is not good at.
You will start collecting much more data. You'll be able to throw as much processing power at your problem as you want to, for short periods of time. You'll be able to effortlessly pull in disparate data-sets and work with them without the effort required to import new data and pre-define relationships and indexes in a SQL schema. You will be able to query unstructured data in multiple formats including video, images, audio, html, plaintext, etc. with more structured data. You will live in a culture of data, where large numbers of PCs are brought to bear on all of your data whenever and however you want. You will discover new relationships you did not know were there. You will get increased value from data you didn't know had value because you didn't bother collecting it, because your DBMS wasn't good at working with that kind of data.
All these are new opportunities that exist in addition to traditional RDBMSes, not in place of them.
> And in the meanwhile SQL is just sooo convenient and easy to develop on.
No, it isn't, it's a pain in the ass because it doesn't match how applications are programmed. I know SQL pretty damn well, and I know how to tune a database very well, and SQL still sucks.
It has it's pain points to be sure, but the fact that "it doesn't match how applications are programmed" is because it's modeling data not code. Yes your object store will make the application much easier to write initially. But then what happens when you need reporting or worse, some feature that you never anticipated that requires a different view into the data.
That's not to say SQL is the end-all-be-all, but people are so quick to dismiss it, and I bet there is going to be a lot of pain felt as code based on simpler databases ages.
Then I replicate the applications data out into a relational database for reporting. 99% of what applications need isn't reporting. I want to use many different data structures, not be forced to fake everything with a table, or continually reassemble things from tables.
SQL has its strong points, being a convenient data store for applications isn't one of them.
Again, it's not convenient for greenfield, but applications don't spend most of their time in that state. A good ORM is a compromise between holding onto that flexibility and being able to reconstruct your data objects easily.
I realize that there are a lot of applications where you will never need that flexibility and a simpler database would be the right choice. My attitude is based a response to the unbelievable hype surrounding these technologies among a certain class of tech blogger. Given how quick many people seem to be willing to chuck the relational model out the window without acknowledging any of its benefits, I predict there will be a lot of rude awakenings and failed projects in the next 10-20 years.
> I predict there will be a lot of rude awakenings and failed projects in the next 10-20 years.
As opposed to the many many failed or stuck projects out there now because they made the mistake of using a relational database as an integration point between many applications and can't risk changing anything now because that one big global variable (the db) can't be touched without breaking 15 applications.
The relational folk don't like to admit their shortcomings either.
I should have said "some people". I don't think developers in general are dismissing SQL. I just think there's a certain vocal minority who has a loathing so great for SQL that they willfully ignore the power of the relational model in their analyses of why some of these new DBs are so great.
