一種優(yōu)雅實現(xiàn)多表查詢的新思路
哈嘍，各位代碼戰(zhàn)士們，我是Jensen，一個夢想著和大家一起在代碼的海洋里遨游，順便撿起那些散落的知識點的程序員小伙伴。
上一篇文章有一些小伙伴在吐槽我的AC架構：
這里我統(tǒng)一補充：AC架構不是銀彈，不適用于所有場景。對于需要精細化管理接口的業(yè)務，還是要拆開一個個接口去寫；而對于小而美的微服務、單表CRUD比較多的管理后臺，采用AC架構可以節(jié)省大量重復性編碼。
也有很多小伙伴私信我：使用AC架構怎么解決聯(lián)表查詢問題？本文將為大家揭曉。
本文涉及技術點：存儲方式、內(nèi)存聚合。
一、冗余存還是范式存
冗余存儲的優(yōu)缺點：
優(yōu)點：
- 查詢性能：冗余存儲可以通過減少連接操作來提高查詢性能，因為所需數(shù)據(jù)已經(jīng)被存儲在了同一個地方。
- 減少I/O：在查詢時，可以減少磁盤I/O操作，因為所有數(shù)據(jù)都在同一個表中。
- 簡化應用邏輯：應用層不需要處理復雜的多表關聯(lián)，簡化了應用邏輯。
缺點：
- 數(shù)據(jù)不一致：冗余數(shù)據(jù)可能導致數(shù)據(jù)不一致性問題，特別是在數(shù)據(jù)更新時，需要確保所有冗余的副本都被正確更新。
- 存儲空間：冗余存儲會占用更多的存儲空間，因為相同的數(shù)據(jù)在多個地方被存儲。
- 維護困難：隨著數(shù)據(jù)量的增加，冗余數(shù)據(jù)的維護變得更加困難，任何結(jié)構變更都可能涉及到多個表的修改。
范式存儲的優(yōu)缺點：
優(yōu)點：
- 數(shù)據(jù)一致性：范式化減少了數(shù)據(jù)冗余，有助于保持數(shù)據(jù)一致性。
- 存儲效率：通過消除重復數(shù)據(jù)，可以節(jié)省存儲空間。
- 數(shù)據(jù)完整性：范式化有助于實施數(shù)據(jù)完整性約束，如實體完整性、參照完整性等。
缺點：
- 查詢性能：范式化可能導致查詢性能下降，因為需要執(zhí)行多表連接來獲取完整數(shù)據(jù)。
- 增加I/O：多表連接可能會增加磁盤I/O操作，特別是在涉及大型表的情況下。
- 復雜查詢：應用層可能需要編寫更復雜的SQL查詢來處理多表關聯(lián)。
我們再復習一下大學老師教過的數(shù)據(jù)庫范式（Normal Forms）：
范式化是數(shù)據(jù)庫設計中的一個概念，旨在減少數(shù)據(jù)冗余和提高數(shù)據(jù)完整性。有幾種不同的范式，包括：
- 第一范式（1NF）：每個表格的每個列都是不可分割的基本數(shù)據(jù)項。
- 第二范式（2NF）：在1NF的基礎上，所有非主屬性完全依賴于主鍵。
- 第三范式（3NF）：在2NF的基礎上，沒有傳遞依賴，即非主屬性只能依賴于主鍵，不能依賴于其他非主屬性。
在實際應用中，完全遵循范式化可能會導致查詢性能問題，因此通常會根據(jù)實際情況進行適度的反范式化（Denormalization），即有意引入一些冗余來優(yōu)化性能。
設計數(shù)據(jù)庫時，需要在數(shù)據(jù)一致性、存儲效率和查詢性能之間做出權衡。
二、走進“聚合”
“聚合”二字經(jīng)常出現(xiàn)在程序員之間、程序員與產(chǎn)品經(jīng)理的對話中，雖然產(chǎn)品不懂技術語言，他們只管給客戶實現(xiàn)特定需求，為技術提供產(chǎn)品原型，但是技術比較關心到底是冗余存還是范式存。
如果涉及的數(shù)據(jù)需要分表存儲，單表查滿足不了客戶需求，這時就需要進行數(shù)據(jù)聚合，傳統(tǒng)的方式是寫SQL，Join連接多張表，返回多張表的數(shù)據(jù)給前端，這種方式對數(shù)據(jù)庫查詢有一定的壓力，整體性能雖然較好，但缺點也很明顯：
隨著業(yè)務量越來越大，工程里的SQL會滿天飛，并且SQL會寫得越來越復雜，對維護SQL的人簡直是噩耗！
這意味著什么？代碼寫了兩三年后，SQL已經(jīng)很難維護了，沒人敢動，每次看SQL都特別費勁，還不知道哪一天會出現(xiàn)慢SQL。
其實除了寫SQL語句，我們還能通過倉庫實現(xiàn)層做數(shù)據(jù)聚合，這就是所謂的“內(nèi)存Join”，把數(shù)據(jù)庫壓力轉(zhuǎn)移到了不要錢的CPU與內(nèi)存中，具體方法如下：
- 查詢參數(shù)Query對象添加Boolean fillXxx字段，用于控制是否要聚合。
- 倉庫實現(xiàn)XxxRepositoryImpl實現(xiàn)fill(Query query, List<Model> models)方法，models就是查詢出主表的結(jié)果集，通過query.fillXxx=true控制聚合其他表的數(shù)據(jù)。
這個fillXxx就是聚合參數(shù)，大多數(shù)情況下是默認關閉的，也就是默認還是單表查詢，如果需要聚合，由前端傳參控制，這樣既可以兼顧性能，也可以兼顧功能，我們按需聚合數(shù)據(jù)即可。
下面我們看看一個真實案例，預約單倉庫實現(xiàn)，聚合預約主體、預約記錄、預約主體評價：
/**
* 預約單倉庫實現(xiàn)
*/
@Repository
public class AppointmentOrderRepositoryImpl extends
BaseRepositoryImpl<AppointmentOrderMapper, AppointmentOrder, AppointmentOrderPO, AppointmentOrderQuery> implements
AppointmentOrderRepository {
// 聚合方法
@Override
public void fill(AppointmentOrderQuery query, List<AppointmentOrder> appointmentOrders) {
Map<String, AppointmentOrder> orderId2appointment = appointmentOrders.stream().collect(Collectors.toMap(AppointmentOrder::getOrderId, o -> o));
if (query.getFillAppointment()) {
// 聚合預約主體
this.fillAppointment(appointmentOrders);
}
if (query.getFillAppointmentRecords()) {
// 聚合預約記錄列表
this.fillAppointmentRecords(orderId2appointment);
}
if (query.getFillAppointmentComment()) {
// 聚合預約主體評論
this.fillAppointmentComments(appointmentOrders);
}
}
private void fillAppointment(List<AppointmentOrder> appointmentOrders) {
// 通過預約單的主體ID列表（去重）查詢主體
Set<String> appointIds = appointmentOrders.stream().map(AppointmentOrder::getAppointId).collect(Collectors.toSet());
List<Appointment> appointments = AppointmentQuery.builder().idIn(appointIds).build().list();
if (CollKit.isEmpty(appointments)) {
return;
}
// 按主體ID映射，把主體的信息寫到預約單內(nèi)
Map<String, Appointment> map = appointments.stream().collect(Collectors.toMap(Appointment::getId, o -> o));
for (AppointmentOrder appointmentOrder : appointmentOrders) {
Appointment appointment = map.get(appointmentOrder.getAppointId());
if (appointment != null) {
appointmentOrder.setAppointment(appointment);
appointmentOrder.setAppointName(appointment.getName());
}
}
}
private void fillAppointmentRecords(Map<String, AppointmentOrder> orderId2appointment) {
// 查出指定預約單ID列表的預約記錄
List<AppointmentRecord> appointmentRecords = AppointmentRecordQuery.builder().orderIdIn(orderId2appointment.keySet()).fillTimeSchedules(true).build().list();
if (CollKit.isEmpty(appointmentRecords)) {
return;
}
// 按預約單ID分組，讓預約單關聯(lián)多條預約記錄
Map<String, List<AppointmentRecord>> map = appointmentRecords.stream().collect(Collectors.groupingBy(AppointmentRecord::getOrderId));
for (String id : map.keySet()) {
orderId2appointment.get(id).setAppointmentRecords(map.get(id));
}
}
private void fillAppointmentComments(List<AppointmentOrder> appointmentOrders) {
// 查出指定預約單ID列表的主體評論
List<String> orderIds = appointmentOrders.stream().map(AppointmentOrder::getOrderId).collect(Collectors.toList());
List<AppointmentComment> appointmentComments = AppointmentCommentQuery.builder().orderIdIn(orderIds).build().list();
if (CollKit.isEmpty(appointmentComments)) {
return;
}
// 按預約單ID分組，讓預約單關聯(lián)首條預約主體評論
Map<String, List<AppointmentComment>> map = appointmentComments.stream().collect(Collectors.groupingBy(AppointmentComment::getOrderId));
for (AppointmentOrder appointmentOrder : appointmentOrders) {
appointmentOrder.setAppointmentComment(CollKit.isNotEmpty(map.get(appointmentOrder.getOrderId())) ? map.get(appointmentOrder.getOrderId()).get(0) : null);
}
}
}需要注意的是，fill方法要對多條結(jié)果進行批量處理，如果是單個結(jié)果，每一條結(jié)果都需要聚合多表數(shù)據(jù)，那勢必會加大內(nèi)存與數(shù)據(jù)庫連接的負擔。以上預約單表聚合其他三張表，比SQL的Join多調(diào)了3次查詢，但好在邏輯清晰，減少維護SQL的負擔。
聚合查詢的打開方式就很簡單了，如果前端不傳聚合參數(shù)，那么由后端接口來控制：
// 設置聚合參數(shù)（或由前端傳入）
query.setFillAppointment(true);
query.setFillAppointmentRecords(true);
query.setFillAppointmentComment(true);
// 分頁查詢后，會自動調(diào)用fill方法，對結(jié)果集聚合
Page<AppointmentOrder> page = query.page();
// 調(diào)用聚合方法（以下代碼在D3Boot框架內(nèi)已實現(xiàn)，不需要寫）
appointmentOrderRepository.fill(query, page.getRecords());我們通過這種方式來靈活聚合多表數(shù)據(jù)，不僅不用改動Controller，還能兼顧多種數(shù)據(jù)聚合的場景，這種數(shù)據(jù)的聚合，不一定要聚合數(shù)據(jù)庫的數(shù)據(jù)，也能聚合第三方接口的數(shù)據(jù)。倉庫接口只關心需要提供什么數(shù)據(jù)即可，怎么聚合數(shù)據(jù)、數(shù)據(jù)源來自哪兒，是倉庫實現(xiàn)要負責的事情。
三、寫在最后
目前這種聚合方式也只適用于大部分場景，對于多張大表的聚合，還得考慮是用數(shù)據(jù)庫Join還是內(nèi)存Join的方式進行，或者在設計的時候就要考慮冗余存而不是范式存。
