CREATEVIEW NiceList ASSELECT*FROM Children
WHERE behavior ='nice'AND parent.income >40000;
CREATEVIEW NaughtyList ASSELECT*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.
Why would Santa need two separate tables for this?
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';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
But not the poor nice ones
The poor nice ones get beaten by the naughty rich ones.
Why are we using magic strings for behavior?
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
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 tonaughtyandniceonchildidand both record their status each year so that he can monitor trends.