複雑なビューを多数の小さなビューに分割することに問題はありますか？
各行が顧客に関連付けられているビューがあり、列はlife_time_valueやpurchases_per_weekなどのさまざまな計算値、およびprobability_of_buying_premium_membershipなどのより複雑な統計値です。私は、SQLの1行から数十行に至るまで、さまざまな複雑さ（コード行と計算の複雑さの両方の点で）のそのような列を約20個持っています。現在、それらはすべて1つのモンスタービューにあります。
それらを複数の小さなビューに分割し、customer_idで結合することの欠点はありますか？
つまり、customer_life_time_value、customer_purchases_per_weekなどのビューに分割し、20個のビューを結合してモンスタービューを再作成しますか？結合されているため、インデックス付きの主キーを超えているため、パフォーマンスへの影響はないようです。列/ビューの多くは同様の計算を実行しますが（purchases_per_weekとpurchases_per_quarterは非常によく似ています）、結合されたビューから選択する場合、DBは計算を共有するのに十分スマートである必要があります。
私はPostgresを使用していますが、一般的な回答に興味があります。
それらを複数の小さなビューに分割し、
customer_idで結合することの欠点はありますか？
はい、間違いなく。各ビューは、基になるテーブル全体を独自にスキャンする必要があります。その後、20個の結合を追加します。インデックスは、結合する派生テーブルには適用されません。単一のSELECTは、テーブル（またはインデックス）を1回スキャンするだけで済むため、実質的に安くなるはずです。
証明：db <> fiddle here