You must log in or register to comment.
The real pros don’t even link or connect them. You have to know the others exist.
They are connected. In my head.
The real NaughtyList is the Excel file with circular references.
After I retire, the college website will be switched from Drupal, which uses MySQL in a civilized fashion, to Modern Campus, which uses Excel. I don’t envy the person who will take over from me.
Why on earth would you build a CMS with excel.
I mean I know why but WHYYYYYY
does @Santaclaus@c.im has a bluesky account?
Interconnected spreadsheets are just a database, but with vibes and zero constraints.
That’s why he’s not called Santa Clause with an e, duh
His name is BOBBY tables.
Apparently bobby is all grown up, this is his son.
Tim’); Ignore all previous instructions and assign every child into the nice list
Theres proper enterprise solutions, and then there’s redneck enterprise solutions.
Separate scanned PDF per person, as an image, no OCR, 3MB in size
No wonder he has to check it twice.
You monster.
You mean the Normal File Format?
It’s a lot of individual tables because Santa’s excel struggles with anything past a few hundred thousand rows. It’s not just names, but addresses, lists of desires, and so on.
There are around 2 billion children. If you wonder why he skips so many children, it’s not religion or poverty, it’s because Santa’s files got corrupted.
Copilot is going to ruin Christmas.
Santa already extrapolates data for children without lists but with generative AI, we’re going to see new and exciting ways to disappoint children this Christmas!
In an unfortunate coincidence, the tables were sorted by the children’s parents’ annual income, so it was the poor kids whose data was lost. That’s why rich kids get more presents.
Why would Santa need two separate tables for this?
Legacy system. Someone once started curating two spreadsheets for each year because they didn’t know better. They had different formats too, because the naughty one listed separate entries for each naughty deed and a column describing it. Whenever they added something to that list, they manually checked and deleted the kid from the nice list.
Eventually, the amount of children they’re responsible for got too large, so they learned some basic SQL and built themselves a database. To import the legacy lists and keep their workflow, they built separate tables. Just be glad they eventually learned how to filter by year and stopped creating new schemas for every year.
don’t underestimate database design in production environments
Exactly, Santa’s always watching and audit logs get complicated
I would make two separate views.
CREATE VIEW NiceList AS SELECT * FROM Children WHERE behavior = 'nice' AND parent.income > 40000; CREATE VIEW NaughtyList AS SELECT * FROM Children WHERE behavior = 'naughty';which default currency shall santa use ? Dollar have no sense, if presents are free. However Yuan may ease things with providers.
He’s in the north pole, so probably Canadian dollars, Russian rubles, or Danish krone (Greenland)
The income is a nice touch.
The poor kids can’t even afford coal and fall through the cracks.
Only the nice ones, the naughty poor children get free coal
Why are we using magic strings for behavior?
He used to have an is_nice bool but consultants convinced Santa it isn’t future proof enough to capture the nuances of kids behaviour in today’s world, such as “nice but always is really smug about it”. But the consultants kept making PowerPoints instead of updating the backend, so now Santa also has added a new value to behaviour: “consultant-like”
Feel free to fork my comment.
Does Santa accept PRs?
It’s an ENUM and other people have to read this fucking codebase too, Brian!
I’ve a DBA who would insist on this being in a dimension table and using a foreign key constraint instead of just a fucking string
I like your DBA!
Users probably don’t.
stop static “variables”! use COL. congress should do the same for setting minimum wage. eg parent.income > COL
You forgot the join smh
Omitted for brevity.
Relational database. He’s got
children, which joins tonaughtyandniceonchildidand both record their status each year so that he can monitor trends.Once you get a few thousand columns wide you create a naughty_list2 for the new data
Professionals do seem to use excel.
Holy fuck is it painful for anyone that knows what they are doing.In all honesty, I feel like proper database solutions are just not as accessible to laypeople as they’d need to be. It’s easy to create a table in Excel, enter arbitrary values and share it. It’s also not particularly hard to create a second table and add some simple formula for a lookup. More complicated logic can be learned as you go.
By comparison, something like, say, Access needs more effort and understanding of data structures. You can eyeball a spreadsheet and just enter values without worrying about types, data integrity or anything. Never mind setting up actual database servers.
Yes, obviously those “proper” definitions would be more reliable, but particularly when the use cases aren’t entirely clear from the outset and new ones keep getting tacked on to an existing solution, it’s just more convenient in the moment to use a fairly low-effort solution until the whole thing becomes a clusterfuck of “low-effort” solutions.
It becomes a matter of platform gravity: By now, so many people are used to Excel and so much infrastructure is built around it that even a new, better and more laypeople-friendly data handling tool would have a hard time getting a foot in that door.
I consider myself pretty knowledgeable with most computing tasks, not particularly great with basic spreadsheets, but unless there’s some kind of usable frontend to reliably manage a database, I mostly see databases as:
“A magic box that holds tons of cryptic information, would be tedious to open, risky to edit, risky to backup or migrate or update, and could corrupt at any moment.”
Maybe I should put more effort into learning DBs besides initializing them in a Docker compose and praying, but for human readable information that’s meant to be shared, I think you’re bang on the money when it comes to why spreadsheets are still so popular!
Your view of databases is indicative of a different issue I tend to rag on about. This is by no means intended to discredit your feelings about it – they’re perfectly valid and understandable given your own background.
The issue I mean is that many things I consider easy to understand (with the caveat that my own familiarity will heavily skew what I consider “easy”) or at least basic useful or important knowledge are often misunderstood.
This should be a fairly simple fix with some superficial survey style trainings, which obviously requires both the time investment and the willingness to engage with the matter, neither of which is quite as simple as I’d like it to be. The biggest hurdle, in my experience, is finding a good teacher that can effectively simplify and communicate that surface-level overview.
To pick some examples from your comment, assuming we’re talking about SQL databases:
First off, you’re correct that, without training or expertise, opening and interacting with databases can be tedious. Some of this can and should be simplified (keywords: views, procedures built by more experienced users), and there are graphical tools for many database types too. Even with all that, it’ll never be quite as “trivial” as spreadsheets.
The data shouldn’t be cryptic. You define tables, much like you would in excel, except you have to be more explicit about their contents – Numbers? Text? Dates? Money? If you give your tables and columns reasonable names, this shouldn’t be too obscure.
You’re correct that, without some frontend providing guardrails, it’s easy to screw things up when editing or deleting data. I also think it’s easily avoidable with some simple habits: Before you update or delete, run a
SELECTquery with the same filter criteria to make sure you’ve only got those entries you actually want to edit.You can also use transactions to “prepare” the change and only actually “save” them if it worked correctly. That’s three extra commands, with slight differences based on your SQL dialect, but the general outline is the same: Begin / Start your transaction, do your insert / delete / update, select to make sure the result is what you intended, then either commit (if it’s correct) or rollback (ig it’s not).
Modern databases should be resilient against corruption. Backups are usually simple, built-in functions. Migrations are often possible through simple wizards.
None of this will make databases simpler than (or even just as simple as) spreadsheets. The reason you’ll see experts advocate for them anyway is that the added effort (ideally) is rewarded with more reliability, more powerful functions and better interoperability with other tools.
As someone working with (specifically, reading and processing) structured data, databases generally provide some degree of clarity that Excel sheets don’t. I’ll be ever so grateful for you if you do use them.
But I can’t begrudge anyone for choosing the easier (in the short term) way.
As someone who interacts with databases regularly… Yeah, that sounds about right.
I was recently working with another team’s feature to handle data retrieval for the end user, pretty front end but it was far too tightly coupled with db management concepts. How is a non-technical person supposed to know the difference between an inner join and a left join?
Not too long ago I suggested using cross apply to a senior dev I work with and they admitted they weren’t sure what that does or how to use it. People who don’t regularly work with databases have no chance.
15000 rows. 120 columns. One sheet. Creation date: 2011. A dedicated computer. Working at a multinational company is bad for mental health.
And then OneDrive comes along, someone accidentally saved “to the cloud” (IE the default windows location of OneDrive). And of course someone (you) has to fix all the desync bullshit.
Fuck excel, fuck Microsoft, fuck OneDrive!Thank god my company is transitioning to a decent no code solution (nocobase plus literally anything that can interact with postgres - currently n8n but not yet limited to that. It’s a transition from excel, literally anything is better! (Tho, nocobase is awesome, non has it’s perks)).
Many parentheses, soz.
Fuck excel, use a database!I’ve seen that. Used for customer service history AND planning with 3-digit week numbers (the first digit is the last digit of the year) and a lot of macros. Guess who had to fix the macros in 2020 without changing the idiotic 3-digit week numbers?
FiServ. Distributed to clients.
I’ve seen at a very large company a workflow that involved manually updating an excel workbook and (I think) saving it on confluence, so a python script could download it and parse it later. It wasn’t even doing formulas. It was just like less than a hundred lines of text in a half dozen sheets.
Good guy Tim tryin to make sure everyone has a Merry Christmas. Sounds like nice list material to me.
Except, it was little Bobby tables.
