As I said, it's a heuristic. If you find that you are telling your developers to use your ORM, then you probably should have gone with a NoSQL database like Riak. You can still do joins, etc. but it's in the context of things like map-reduce, and it makes sure that you can scale despite the joins.
MySQL way: SELECT * FROM a JOIN b ON x WHERE y
NoSQL way: 1) SELECT * FROM a WHERE x 2) Perform join in app layer or stored procedure.
Like it or not, when you scale you will lose one of the CAP, and NoSQL databases do the hard task of delivering an eventually consistent data store to you and letting you express yourself in the RIGHT context, which is not SQL.
You're still conflating different parts of the stack: an ORM has nothing to do with CAP.
> You can still do joins, etc. but it's in the context of things like map-reduce, and it makes sure that you can scale despite the joins.
Either of your examples are commonly implemented in SQL databases, too: this is a routine MySQL optimization to avoid subselects and, amusingly, one which an ORM makes significantly easier to implement:
SELECT * FROM a WHERE x;
SELECT * FROM b WHERE pk IN (…list of IDs from first query…);
Again, the SQL vs. NoSQL question is about your data model and access patterns, not whether you use an ORM or magical thinking about CAP. The line between the two has become quite blurry since there are things like MySQL-backed key-value stores or Postgres extensions which allow it to handle document-store workloads without losing performance or giving up the ability to do flexible queries. This isn't a question of religion: it's just looking at your business, assessing how well you know the access patterns (SQL systems are generally more flexible) and performance requirements and picking the best solution.
Anyone claiming to have a right answer for everyone is wrong.
> Like it or not, when you scale you will lose one of the CAP, and NoSQL databases do the hard task of delivering an eventually consistent data store to you and letting you express yourself in the RIGHT context, which is not SQL.
You've now gone from wrong to very dangerously wrong: there is no scale which is immune to CAP and NoSQL has no magic for avoiding this. Eventual consistency is only appropriate for some problems and, as above, can be implemented on either system. No matter what storage system you choose you're still going to have to make careful decisions about business priorities and test carefully.
MySQL way: SELECT * FROM a JOIN b ON x WHERE y
NoSQL way: 1) SELECT * FROM a WHERE x 2) Perform join in app layer or stored procedure.
Like it or not, when you scale you will lose one of the CAP, and NoSQL databases do the hard task of delivering an eventually consistent data store to you and letting you express yourself in the RIGHT context, which is not SQL.