資料介面在我這種沒接觸過的人眼裡應該就是，A介面接進來的資料傳到A，表，B介面的傳到B表。然後開發人員從A表B表中去了解表，去從表中取資料，然後頁面端整合這些表資料，從而開發。領導也一直說我對資料的業務邏輯一直不懂。我心想：業務邏輯光看錶結構表內容怎麼才能熟悉呢？

直到昨天，兩個開發都忙著處理問題，資料介面問題放那兒沒人處理，我硬著頭皮下載了一個POSTMAN測試軟體，自告奮勇的私聊了乙方資料對接的工程師，憑藉初生牛犢不怕虎的勇氣，給他看介面到底啥原因導致的資料無法傳遞。一番折騰以後，我突然發現——資料介面中的這多個欄位的資料，並不是傳到一張表裡去的！而是傳到不同的表中去的。而且他們介面測試是按照業務節流程節點去測得。比如我吃飯這個“業務”，從點單，到做菜，到吃。他比如測了其中的點單環節的資料介面，其中用到了人員表的點單人員資料，用到了價目表中的菜品價目資料，用到了庫存表的庫存數量資料等。這麼一段JS中，包含了這個業務流程所需要呼叫的所有需要用到的表的所需要用到的欄位。終於恍然大悟為啥開發能第一時間透過資料對接或者程式碼就知道哪些表用於什麼業務流程，具體看哪幾個欄位就可以了。我也可以透過這介面文件先摸清整個業務流程（而不是從功能介面上去摸索），然後透過每個測試的業務流程功能節點的資料走向，查清每個欄位去了哪些表。從而將業務功能和資料表的邏輯關聯起來。

其實很多DBA對於業務資料並不熟悉，很多人也秉持著不需要了解業務邏輯，只需要知道業務爆發點，增長點這些情況就可以了。但是很多情況下，特別是非專業運維公司或者團隊，他們需要DBA去做一些資料同步，資料對接，需要和開發溝通去完成專案。所以瞭解業務邏輯和表之間關係是很必要的。