Everything you've mentioned is standard to SQL databases. If you have a schema you don't need NoSQL. Use an ORM for SQL for the language of your choice. Pretty much any db will run as a single node but you should never do that in practice, redundancy is security is stability
Sure, but by that argument I don't need SQL either. I am not sure what your point is?
Anyway, the selling point (for me) is that I don't need to find some fancy ways to translate my schema to relational schema. For instance, let's say I have some text content in two languages; in relational DB the texts should probably go to a separate table and I should reference the main record by some foreign key. In document-oriented DBs I can just put both of the texts inside the record... To me that makes much more sense.
But yeah, if you are a hardcore SQL user who is used to normalizing the data until it hurts (as someone else commented) it is difficult to break out of the habit.
And after you eliminate SQL as an alternative (in my case) there are not many options left. At least I couldn't find (m)any.
If you know you are only storing two languages, they can go directly on the parent table, named english_text and spanish_text. If you are talking about the easyness of storing a hashmap in NoSQL, ie:
{
english :'text',
spanish : 'text',
french: 'text'
}
You can achieve this in the same table with the JSON storage type:
Really though, a decent ORM will take care of all the foreign key implementation, and a hashmap is well served by a 2nd table called 'texts' with 3 columns. I can see why you would be opposed to this, because of the extra join but given the right indexes it won't be slow at all.
