don't underestimate database design in production environments

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'; 

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.

Relational database. He's got children, which joins to naughty and nice on childid and 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

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.

Copilot is going to ruin Christmas.

15000 rows. 120 columns. One sheet. Creation date: 2011. A dedicated computer. Working at a multinational company is bad for mental health.

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'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.

You mean the Normal File Format?

edit: there's an updated version of this where the only way to get at the document is to download it from the unofficial Whatsapp group.

Apparently bobby is all grown up, this is his son.

They are connected. In my head.

Why on earth would you build a CMS with excel.

I mean I know why but WHYYYYYY

Listen, there's room in SQL for more than one input sanitization joke.