3 ms·
> slather a battery of views over your data One needs to be careful with this approach in terms of query performance, though. Using simple views with a couple
by fuy 4y ago
> slather a battery of views over your data
One needs to be careful with this approach in terms of query performance, though. Using simple views with a couple of joins and some filtering is fine, but be very wary of stacking more than 1-2 layers of views calling each other, and especially of using things like aggregates/window functions in views, if these views then are then used as building blocks for more complex queries.
That's a recipe for breaking query optimizers and ending up with very bad query plans.
- fbdab103 4y agoUse case dependent. When I am tasked to generate some ad hoc analyses, performance is a non-issue. The query is only going to be run the handful of times while I iterate on the idea, and I would much prefer some convenience views rather giving a hoot about optimal query planning.
- fuy 4y agoSimple views are perfectly fine - it's mostly nesting of views with aggregate functions and other complicated stuff that is bad. And if ad-hoc is a big part of what users are doing with an app/database and you don't care about performance, your angle sounds reasonable. As an app developer/development DBA, I care mostly about performance of the queries that are known at development time, though, so I'm a bit biased.