[dykesa]

I don't know that the solution to "programmers are lazy" and databases are hard is for them to learn a niche concept instead of taking the time to actually learn about data storage or, find someone who knows it well and work with them.

[dragonwriter]

Where I see this being useful isn't as a solution to programmers being "lazy" about learning DBs, but to programmers being "lazy" about dealing with RDBMS schema while rapidly iterating on a new project. Something like this lets you discover the schema as you iterate on the program, which would seem to be a win for agility.

[virmundi]

What I don't get is why do I need a "stable" data store to iterator over? On a project I once didn't get a database until 2 weeks before the actual project was due. Fortunately I was using Spring. So I just mocked the DAL until such time as I actually got a real one. This whole time I changed the contract on the DAL, changed how I used it, etc. Then when the DBA finally got around to having time to make my db I presented him with a decent, thought-out ERD.

Sure the mocks had to do some work, but a simple cache allowed me to perform all of the CRUD operations in memory. I can see doing something similar with Mongo/Couch, but having done the DAL with a pure mock set injected via Spring, I don't really see the point. The same goes for HQL or another lightweight in memory DB + Hibernate/JPA. I assume the model of interaction would work with Python or similar languages too.

[dragonwriter]

Because sometimes you want a product to be available to real users while it is still rapidly developing, especially in an environment using Lean principles.

It's kinda of the opposite of the delivery-date-and-it's-done style of project.

[hmottestad]

I know databases well and I have a good grasp of all the normalisation levels, however quite recently I had a project where I just stored all my data in a big json object and when I was done I found out (because of a new requirement from my boss) I now needed to query this big json object. At that point I really wished I had had my data in a nice sql database from day one.

[VLM]

I would make a microscopic improvement on your otherwise good comment by pointing out "databases" are big and interconnected, but not hard at all.

Hard is stuff like some very obscure sort algorithm which is mysterious but once you figure it out, you can apply the sort.

Big and interconnected is what RDBMS is where knowing only one or a couple topics in isolation makes the whole thing appear useless... if you all you know about is normalization, or the idea of foreign keys, or the idea of indexes, or the idea of transactions, individually it all seems like a waste of time lets just use CSV files. But once you know a critical mass of the (simple) parts, its becomes a valuable tool.

If sorts were like RDBMS then once you understood the quicksort you'd still be inherently unable to ever apply a quicksort unless you also knew the radix sort. But they're not like that.

[pudo]

This is by no means meant to replace an understanding of databases. The typical use case is a web scraper, where you download a lot of messy data into an operational data store before you clean it up and load it into something with a proper model. Many people use mongo for this, but I actually like keeping my data around.