Hi all,
Been a bit quiet here so figured I’d post something that’s more of a feeler than an issue. I’ve noticed a trend when maintaining long running vault projects and figured it’d be good to crowd source some knowledge on this.
After the main body of a migration is complete and the analytics departments are feeling the benefits of building their business logic into the warehouse. We get dribs and drabs of additional logic in key areas that they want to include in the warehouse.
However this results in us building business rule computations for single attributes and satellites being created for storing this single attribute. Fine in principle and not pattern breaking but feels a bit overkill as time goes on there are many more bsats than really necessary but merging them all into one place can be similarly time consuming.
Is this an approach you’ve had to rectify?
Is it your preferred method?
What steps do you take to avoid/encourage this outcome?
Looking forward to your thoughts,
Frankie
2 Likes
There should be just 1 _BSAT_METRICS (or split if different speeds).
Question is split metrics horizontally as columns vs rows.
As columns: easier, compact, 1 row is snapshot of all metrics, but have schema evolution problem of adding new columns for new metrics, or not clean to know if there’s dead metrics not in use.
So maybe store metrics as rows (brule_name, brule_version, metric_value, ..) fixes schema evolution, but harder to get current snapshot of all metrics (or at any date).
As always its sll about how dynamically metrics are, speed, and ultimately getting best balance between performance vs usability/maintenance.
But “no” for single metric values as this explodes BSATs.
Are you suggesting a multi-active satellite for storing each of the different metrics instead of doing it column-wise. I’ve not seen that approach before. Have you implemented this in a project before? I’d be interested to see how it performs compared to a wide satellite with each of the metrics as a column