Five mistakes teams make with a data warehouse
It comes up on almost every project, usually later than it should. These are the ones we run into repeatedly when we audit a data warehouse.
Numbers get quoted in meetings long after anyone remembers how they were calculated. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
What to watch for
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Reporting queries and application queries want different shapes
- Separating them stops reports taking the product down
- Never checking whether the fix actually worked
Start with the questions, not with the schema. Where this goes wrong is almost never a lack of knowledge. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Where to go from here
What this looks like day to day
Most data problems are ownership problems that turned into technical ones. Three things worth confirming about a data warehouse before you move on:
- Someone can say what the current setup is without going to look
- Reporting queries and application queries want different shapes — and you know whether that is true here
- There is a way to tell whether the last change to this helped
The point is not perfection, it is knowing which of these you have consciously chosen to skip.