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

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

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