Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Yeah, I took one course where we used MongoDB. I was like "still unconvinced, but I'll keep this in mind if I run into situations not covered by PostgreSQL." ...I've not run into situations not covered by PostgreSQL. Everything will be covered by PostgreSQL.
Jesus Christ, that's JSON Bourne.
Yes that's right, it goes into postgres.
“You know what ELSE everybody likes? Postgres! Have you ever met a person, you say, ‘Let’s use some Postgres,’ they say, ‘Hell no, I don’t like Postgres’? Postgres is perfect!”
Yeah! Postgres is great!
MariaDB
Let's schedule a meet-up at 00/00 year 0000 to talk about it.
elephant walks in
I 100% agree... If you don't need portable databases. For those, everybody like SQLite (even if it can be annoying sometimes)
You can pry sqlite out of my cold dead hands. Because I'll probably die while using it out of frustration due to the poor performance of triggers.
Tbh trigger performance isn't that much of a concern unless you need to write lots of data, which most usage don't need.
Also try check statements instead or even re-evaluate your schema to prevent them if you really need to.
Personally my death would be multiple write transaction deadlocks. Sadly it doesn't play that well with async code, like with sqlx (rust).
My death was the fact that table lock acquisition is not FIFO.
https://sqlite.org/forum/forumpost/8d7d253df1b9811b4b76c2c4c26ac0740e73d06e9edfeb2ab8aabaebd899cbc8
Thankfully I can at least have FIFO in a single process by wrapping every write transaction in a mutex.
P.S. can't wait for turso's SQLite replacement to have feature-parity and sqlx support.
This is also part of my death, because it's much easier to not deadlock when you are FIFO.
Personally I went for the nuclear option, and any transaction is sent as a tokio task to make sure the transaction keeps getting polled despite other futures getting polled. Coupled with a generous busy timeout timer (60secs) and Wal mode, it works pretty well.
Probably should also put the mutex strategy (perhaps a tokio semaphore instead?) although due to lifetimes it might be hard to make a begin() function on my DB pool wrapper.
... Congratulations. You nerd snipped me. Time for it to go on the todo stack.
Hyped for it too, but wouldn't use until sqlx suport. Compile time checked queries are just so good. I don't use rustsqlite for that reason alone (you often don't need async SQLite anyways)
who needs any of that when you have microsoft access
Ow, my integrity
There is actually an open source alternative for that in the Libreoffice suite called "Base"
Is it actually any good for small personal projects? Just want someone who has used it to answer as I’m considering putting some work into it.
I tested it once and it didn't really impress me. Perhaps you can try using something like Grist.
I have used libre office base and found it's buggy mess.
I sugest to use dbbever for any DB, it's different but at least it's not a buggy mess. Or pgAdmin for Postgresql. Or DB Browser for SQLite
Yeah, but is it web scale?
/dev/null is web scale, it maintains sub 1ms times no matter how much load you give it!
Does /dev/null support sharding?
Yes, you can run as many replicas as you want. It's also incredibly lean on the synchronization bandwidth.
It certainly supports the admin sharting when he finds out where all the data went.
What data?
lololol yusssss
With SQL you scale it when it is required by sharding, read replicas, cache layers, and denormalization.
With NoSQL afaik, we have to deal with the scaling from the beginning by keeping the consistency of denormalized data, that has additional code overhead. Is mongoDB different in this regard?
EDIT: I got whooshed. Thanks for the reference :)
edit edit: Holt shit how did I miss this for 15 years. This is great, stayed accurate all this time.
Shoutout to software that had to deal with y2k and is still popular, gotta be one of my favourite genders.
It’s a reference to this masterpiece: https://youtu.be/b2F-DItXtZs
I've never seen that one. It's a masterpiece for sure. Thanks.
Just fyi you're taking a meme seriously
I manage instances of both mongo and postgres at work.
I'll say Mongo OpsManager is pretty sweet, and HA is way easier on Mongo.
Just use Mongo, it scales so well!
Never understood why anyone chose Mongo. Though I have some funny memories getting rid of it because it was slowing the app down sooo much.
If you need something for storing JSONs and querying, just use ElasticSearch/OpenSearch.
Oh god, all the people storing massive JSON documents, and then having to lock the whole thing to modify sub-entities.
Or add a column next to the json with some data about the json and index that.
But is Elasticsearch web scale?
I say this with all appropriate irony: as the guy that deployed it at for Wikipedia, yes.
Had to roll my own JSON storage system after spending weeks trying to get sqlite to work on Godot/android.
It took a day and will suck at scale because there are no indexes. It just goes through the whole file, line by line when you search for an id.
BUT IT WORKS.
Hopefully the repos and stuff I piled on top have made it abstract able enough I can move it to a real database if the issue ever gets resolved.
I’m confused about your SQLite troubles … it compiles for pretty much everything - as long as you have a file system mapping.
It's not just me, but seems to affect Godot c# deployments to mobile
https://github.com/godotengine/godot/issues/97859
Worked fine on desktop
Ahh, it’s not an issue about SQLite but about whether the right libraries are bundled by Godot. Got it, that explains it.
Just store the JSON in a sqlite table with an extra column or two for commonly indexed stuff....?
No, you misunderstand. Sqlite just does not work when it's packaged by Godot mono for mobile (see the ticket in the other replies)
It worked fine on desktop which made it more frustrating