I’ve also lived through NFTs and Beanie Babies. The argument that “technological advancements have happened in the past therefore such-and-such isn’t a scam” only goes so far.

I want to hear how bad his throat singing is.

Are the bronies ok?

I had a coworker who was really into Berzerk. I 3D-printed him a behelit one time. He was thrilled.

Sigh

Updoot

What th-

Wait. Never mind. I didn’t ask. I didn’t finish the question so you legally cannot answer. Per the… Geneva Convention. Yeah. That sounds right.

There were some lesser ones as well. Jeans was one. And Xavier: Renegade Angel. Probably others that I missed or am forgetting.

Given how much thought a lot of superfans of the Bible give to him, you’d think he was the protagonist.

Maybe they’re secret shippers.

ITT: Lemmys don’t like being told what to do, apparently.

Claude’s a gatcha.

Will you get the rare following instructions loot or the deletes-your-whole-prod-environment loot that you already have 10 of?

Possibly the scariest cult.

Username checks out.

Is this position against lookup or read-only db tables?

Largely, yes.

The kind of cases where I’ve seen people stick things in the database that I thought would better be elsewhere:

• If it’s small and doesn’t need to change between releases, you can save all the moving-part kind of overhead of pulling that data from the database just by throwing that data in the source code. Often times people do this just so they can have a “foreign key” to something in the data in question. But a nice, semantic “enum” sort of field in the database can refer to something static that’s already in memory no problem.
• If it needs to change at an administrator’s or developer’s (or manager’s) whim, it’s probably configuration, not dynamic data. In the Java ecosystem, Spring Cloud Config makes it easy to change configuration without releasing the code. (I mean, in a perfect world, releasing should be as easy and straightforward as changing configuration, but not everyone lives in a company where all the managers have read The Phoenix Project and caught the DevOps bug.) Putting configuration in the database tends to create a big audit trail gap, unless you spend a bunch of effort building a custom audit trail kind of system.
• If it’s big and not (very?) relational, it may be better suited for files in a directory. This can be true even if it does change based on user input. (Users uploading images, for instance.)

Mind you, certain kinds of behind-the-scenes users can still qualify as “users” for purposes of considering whether “it needs to change based on user input”. For instance, if your marketing department (without software engineering expertise) needs to be able to mess around (without software engineering assistance) with marketing materials displayed on customer-facing websites, you probably need a content-management system of some sort, and I don’t think the database is necessarily a bad place to store a lot of that information. (Things like images probably shouldn’t go in the database, but metadata about those images are probably quite reasonable data for the database.)

Also, I’m rethinking the term “user input”. I could certainly see it being reasonable for automated systems to put data in the database. Like, if you have a scraper doing stuff to be displayed to end users, that doesn’t belong in the source code or configuration, and if it’s very relatioal, it could well belong in the database. Maybe it’d be better to say “if it doesn’t change based on client input, it doesn’t belong in the database.”

I’m not trying to be a dick. I’m telling you much (perhaps most) of our “disagreement” is you disagreeing with things I never said.

If it doesn’t have to change based on user input, it doesn’t belong in the database.

Oh my god. I’m not the only one who thinks this!

Good catch. Thanks.

You won’t believe what he looked like after smoking only one marijuana.

Perineum Sunning^wikipedia (SFW, surprisingly.)

PHP is dead, learn Brainfuck