Postgres 15. Same 60 column table I've been posting about, I promise I'll stop eventually.

is_active, boolean. active_flag, smallint. Both populated, both written by something, and they disagree on about 3% of rows. Nobody knows which one the app respects. I spent an afternoon on it and my best finding is that the disagreement rate has been slowly climbing since a 2021 migration, which tells me one of them stopped being maintained and not which one.

This is worse than the columns nobody can explain. flag_2 at least announces itself as a mystery, so nobody builds on it. These two both look like answers. Someone joined in July and spent a week working out which of three status-ish columns actually mattered, and picked wrong first.

What I've tried: grepping for both, which gives me hits in dbt, the app repo and a commented-out block in an old migration. Checking which one the ETL writes, which is both. Asking the two people who've been here longest, who gave me different answers with the same amount of confidence.

what I think I should do is pick the one the app actually reads at runtime, make the other a generated column off it, and let anything that disagrees break loudly. what stops me is that I can't prove which one the app reads without reading the whole app, and the reads I'm worried about aren't in the app anyway, they're in Metabase questions owned by analysts.

so:

• when two columns claim the same thing and disagree, is there anything better than picking one and waiting for screaming
• has anyone made the wrong one a generated column or a view over the right one, and did it actually stop the divergence or just move it
• more generally, do you have any way of catching a column whose meaning drifted while its name and type stayed the same. that's the failure I can't monitor for and it's the one that's actually happened here

Schema changes are a solved problem for us with migrations. What I keep running into is the data side. If someone changes lookup values, config rows, or reference tables in dev, there's no clean way to carry that to prod along with the migration.

How does your team handle this today? Curious whether it's seed scripts, manual dumps, some diff tool, or you just don't let data change outside of prod in the first place.

I create sqlite3 bindings for my new programming language

You can check the GitHub repo: https://github.com/abdorayden/rdn-sqlite3

Also the repo of the language: https://github.com/abdorayden/rdn

Thank you everyone 🙏🏽

Great work!

I am thinking of creating a multiplayer game website online where 2 players can play sql games with each other like sql queries and table or multiple choice question and a timer on it . What are you guys view on it? #sql

Huhu zusammen,

mir liegt eine Lösung vor wie man SQL-Joins und die zugehörigen Constraints über den SQL-Standard hinaus weiter standardisieren und automatisieren kann.

Bin ich mit dem Thema hier richtig in der Gruppe?

Liebe Grüße, Alexander

I’ve noticed that as queries get more complex, there’s often a temptation to keep everything inside SQL—CTEs, window functions, nested subqueries, conditional logic, etc. It can be impressive, but at some point the query becomes harder to understand than the original problem.

Where do you personally draw the line? Is a 300-line SQL query perfectly fine if it’s well structured, or do you prefer moving some of the logic into dbt/Python/application code once the SQL becomes too complex?

I’m curious how others balance SQL performance, readability, and maintainability in real projects.