Why not just a plain json file instead of a database?

Why not search in books instead of Google?

To avoid re-implementing things like I/O, storage optimization, compression, indexing, security, schemas, sharding, partitioning, audit, backup, et al. Not to mention queries.

@SortOfTested humm

thats basically mongoDB with less steps

@sleek ooh burn!

Profound dumbness detected.

Danger.

What @SortOfTested said is one part of the deal.

The other (and that's where the fun part happens) is making a ""file"" (data store would be better) readable and writable concurrently without fucking it up.

It's the concurrently and not fucking it up where true terror lies. MVCC is in it's principles simple, but the implementatiojs are usually a clusterfuck.

As an example FSYNC behaviour on different OSes with different filesystems and different sync implementations and hardware dependent behaviour...

FSync Gate in PostGres if u want to read a small part of why this is a clusterfuck.

You are free to do so, Everything at one place is never a good idea.

Why just not use an excel spreadsheet? #ukgovernment

@IntrusionCM Not nice... clearly he is asking an honest question, it has nothing to do with dumbness.

for table data please use csv instead of json

@pxeger I said "profound dumbness _detected_".

I didn't say: The author is profound dumb.

It has nothing to do with the author as you imply - which is shady in my opinion.

It's more that it's obvious that the answer cannot be trivial and that - if A was possible - people wouldn't do B.

Profound dumbness as the more you'll try to answer the question, the deeper you'll have to dig in all kinds of research and realize your own lack of knowledge.

Which includes my own lack of knowledge. I was pretty shocked when I first read PostgreSQL FSync Gate... For several reasons ;)

It depends on the use-case. Sometimes a plan and simple JSON is a better choice than a DB. Other times a DB is a better option.

It depends on the context.

short: it depends

long:
if you want to save 5 lines of config data, a json is perfectly okay. or if you want to send a small network object to a client application too.

if you try to save a million users with a million config entries, a json becomes very impractical, it takes forever to read save or search, you have no query abilities, filters or access by more than one user at a time.
in general, if you would need that file more than once a second, you are past the limit imo.

You usually define your data structure before making it.
if you have relations (eg a customer having orders) thats a pointer towards a relational database.
if you have a local config file with a few lines, that you always load as a whole anyways on startup, thats the use case of a local file.
it is probably good to note that json may not always be the best notation for each case either. by my experience its mostly used for data transmission in networking.

@yowhatthefuck oh, you remember, anything in public domain is not a good idea either.

Eeeeewwwwwwwwwwwwwww