最近梳理業務代碼 ，在考慮一個問題，是不是可以去掉所有的關聯查詢。
1、儘可能利用數據庫的關聯查詢，避免在業務層增加過多的業務邏輯。
優點：
這麼做，業務代碼 相對比較簡潔，開發效率也比較高。尤其是在多個微服務共享共享數據庫的情況下，這種方式 開發還是比較方便的。
缺點：
但是如果開發人員不注意SQL的優化，很容易容易出現慢查詢，甚至很多表關聯到一起的情況。後期做微服務拆分，也會非常痛苦。
2、 儘可能去掉關聯查詢，總體原則就是將計算的工作 放到微服務層。
所有都是單表查詢，然後在service 層 可以有效使用Stream 流式計算 解決問題。
舉個例子，如果涉及多張表的關聯查詢 ，可以是如下流程
查詢A表--通過Stream 流式計算過濾出數據--->查詢B表--->通過Stream 流式計算過濾出數據-->查詢C表。。。。。， 以此類推，將計算的工作量 放在 service 層。
優點： 表優化比較簡單，避免慢查詢，有利於微服務拆分。
缺點： 會增加 數據庫磁盤的壓力 和帶寬傳輸的壓力。如果要避免這個問題， 就要注意一個問題，就是查詢的順序 ，應該優先查詢數據少的表。
(3) 綜合上面兩個方面
項目初期， 概念設計 很難完善，趕進度比較重要，或許第一種方式 是比較好的。系統成熟到一定程度時，會出現數據量比較大的表，對於大數據量的表，我覺得第二種方式比較可取，但一定是使用批量查詢。