I have a view where each row is associated with a customer, and the columns are various computed values such as life_time_value
and purchases_per_week
, as well as more complicated statistical values such as probability_of_buying_premium_membership
. I have around 20 such columns of varying complexity (both in terms of lines-of-code and also computational complexity), ranging from a single line of SQL to several dozen. Right now they are all in one monster view.
Is there a down-side to splitting them into multiple smaller views and joining them by customer_id
?
Ie, break it down into views called
customer_life_time_value
, customer_purchases_per_week
and so on, and then recreate the monster view by joining 20 views? It seems like there shouldn't be a performance hit because of the joining, as it's over a indexed primary key. Many of the columns/views will perform similar calculations (purchases_per_week
and purchases_per_quarter
would look very similar), but it seems like the DB should be smart enough to share computation if I am selecting from the joined view.
I am using Postgres, but interested for answers in general.