I’ve been trying to build a dashboard for our sales pipeline, and I keep hitting a wall with the underlying data model. My fact table is getting huge because I’m pulling in every single interaction, but the business really just wants to see the current snapshot of each deal. I’m wondering if a data vault approach would actually make this easier to manage in the long run, or if I’m just overcomplicating things for a relatively simple report.
Data vault can help you separate changing elements from stable ones so the current snapshot isn't buried in a wall of history. It does add complexity and you may still need PIT style components, but it can aid governance and rebuilds when you move beyond one dashboard.
Sounds like overengineering for a simple current view. A lean snapshot table with a daily upsert could be simpler and faster than dragging in every interaction yet still give you the current state. data vault feels heavy for this pull unless you already have a data governance program in place.
I may be misunderstanding the problem but storing every touch point worries me that the table becomes unwieldy. A compact current state table plus a separate change log can surface the latest deal state without flooding the dashboard.
Why not frame the problem as a need for a single authoritative deal current model and work from that with clear keys and filters rather than choosing a vault based approach? If the goal is speed the vault may be unnecessary.
Think governance and lineage first. A data vault can help you trace origin sooner, but the dashboard still wants a fast view of the present state. Maybe a hybrid with some pre aggregated layers works better.
From a user angle the latest numbers matter more than the log of every interaction. I keep edges loose and lean and that makes the dashboard feel responsive even if the underlying model is messy. It might be a trade off.