I've wasted too much time trying to do things in No SQL document databases like Mongo.
Would have been far better to default to PostgresSQL / SQLite. If one thing you build turns out to be better suited to something else you can change it later. More difficult to go the other way.
Just use SQL.
Would have been far better to default to PostgresSQL / SQLite. If one thing you build turns out to be better suited to something else you can change it later. More difficult to go the other way.
Just use SQL.
Comments
I have a soft spot for Cassandra and maybe Redis, but I see it as a cache and quasi message broker.
IIRC I just went “but why?”
It’s not like columnar DB’s weren’t already being used and readily accessible in the org either!
But hey, CouchDB is has some pretty nice features for replication.
Which is a problem
Can do a write back cache or a scheduled job for denormalization.
12ms response times. Literally as fast as many monitor refresh rates.
It seems to me that 80-90% of information storage ends up needing to be in a relational DB, though.
If you ever really need something else you’ll likely have enough cash to pay for a bunch of database experts to make that decision for you.
In general, case two actual is more common for most people. And the real kicker is most modern SQL DB support indexing and data types that match the nosql pattern anyways.
SQL is fine on the another hand.
From my pov you are trolling mainly because mongodb is super flexible and easy to learn.
https://www.youtube.com/watch?v=A2NnemrKHNI
Most of the data I care about, though, has relationships to other data, and would benefit from an RDBMS.
I've also seen it work well.
It just works well far less consistently than Postgres and so isn't worth the risk IMO.
I mean, I agree, you should start on an actual ACID DB, preferably with an OSS and standardized interface, but am I mistaken that it's pretty easy to migrate the data out of Mongo?
There's a handful that aren't.
why ignore 30-40 years of solid track record, a brilliant language like SQL, a mathematical footing in set theory?
all b/c "my data isn't relational. it's a document."
fine. add key fields and store the document as a blob/clob.
Maybe it makes sense in some cases, but in general plain SQL has never failed me.
At the time I liked that it gave me an opportunity to learn about map reduce... but I've never needed that in any of the successful businesses I've worked in since.
This seems an almost-appropriate place link to my fave comic on the subject http://howfuckedismydatabase.com/nosql/
prescriptionists are going to prescriptionist 🙄
but then a transactional need comes up and oh god you're rolling your own notions of transactions _over http_? good luck
Postgres is good enough for almost any use case.
Most people I've run across who use NoSQL do it just to be different, and then I end up re-writing it and using SQL anyway when they give up.
SQL is the very essence of the Universe.
SQL is the forty-two.
I'm just glad I've never needed it.
I've been working on something similar but most of the good tools for migrating aren't maintained any more.
Almost like all the smart people have already migrated ;)
Which one?
I found this one in Ruby:
https://github.com/stripe-archive/mosql
And this one in Go:
https://github.com/zph/moresql
Both archived.
Now I mainly just have to gauge if I "should" move forward with certain requirements, or push back on our business unit to reduce our headaches in a PI or two
Ended up reimplemting indexes and foreign keys in Javascript!
Folks should at least know Codd (1970) and *why* RDBMS!
So dumb.
Allowed for conditions if data collected on multi nodes. And saved so many connections to sql db
No SQL is dump yard of data