Hacker News new | ask | show | jobs
by protomyth 1875 days ago
Well, yes but. Why do you need 15 tables for analysis queries and why isn't someone rolling those tables into something a bit easier with some backend process.
4 comments

> why isn't someone rolling those tables into something a bit easier with some backend process.

You'd identified why we're all going to have jobs in 100 years.

Automation sounds great. It's exponentially augmenting to some users in a defined user space.

Until you get to someone like me, who looks at the production structure and goes: "this is wholly insufficient for what I need to build, but it has good bones, so I'm going to strip it out and rebuild it for my use case, and only my use case, because to wait for a team to prioritize it according to an arcane schedule will push my team deadlines exceedingly far."

This is why you don't roll everything into backend processes. Companies set up for production (high automation value ROI) and analytics (high labor value ROI) and has a hard time serving the mid tail. EVERYTHING on either direction works against the mid-tail -- security policies, data access policies, software approvals, you name it.

People, policy, and technology. These are the three pillars. If your org isn't performing the way it should, then by golly work at one of these and remember that technology is only one of three.

Tree pillars where you only can choose two to be perfect. Just like databases and CAP theorem
Technology is the easiest to adjust, ironically.
This is where I think the original data admins were deluding themselves. Expecting 1,400 analysts to write better code is a really non-trivial problem, but easy to proclaim.

An actual solution is creating pre-joined tables and having processes ("Hey your query took forever, have you considered using X?") or connectors (".getPrejoinedPatientTable()") that make sure those tables are being used in practice.

> why isn't someone rolling those tables into something a bit easier with some backend process.

To put it in more concrete terms(plain SQL): the tables could be aggregated on a set returning function or a view.

Yes, in these situations materialized views with indexes are generally the correct answer.
May I introduce: Protomyth, meet DW and ETL.