在數字化浪潮洶涌澎湃的當下，傳統企業置身于技術十字路口，面臨諸多關鍵抉擇，其中業務邏輯處理究竟安置于何處，是依托應用側，還是借助數據庫的存儲過程和 SQL，有時候還挺難說哪個更合適。這絕非簡單的二選一，而需依據不同業務場景與實際需求細細權衡。

圖片

在國內，前些年受到聯網企業主導的去 IOE 工作影響，“數據庫向后退，應用向前走” 一度成為主流走向。上周末，來自加拿大的 OMINIGRES 創始人尤里提出 “database is the business architecture”，反映出了北美中小用戶在系統建設上的不同選擇，意味著將數據庫與數字化業務深度融合，充分挖掘數據庫潛能構建業務系統，這樣可以大大節約中小企業的IT投資。北美的IT建設注重實效，講求性價比，不像我們，哪怕IT投資十分捉襟見肘的企業，不搞個中臺，用點微服務，CIO就好像沒干好一樣。

重視可維護性與代碼可讀性的企業業務系統，應用側承載業務邏輯優勢顯著。以大型電商平臺繁雜的訂單處理流程為例，從用戶下單瞬間起，庫存扣減、支付確認、物流調配等環節便緊密交織，且隨市場動態、客戶喜好頻繁調整。此時，若選用應用程序代碼，如 Java 等編寫，開發人員遵循面向對象編程規范，代碼結構清晰，團隊成員能輕松洞察業務邏輯脈絡。版本迭代時，借助各類開發工具，代碼變更追蹤易如反掌，持續集成與部署高效推進。同時，完善的單元測試框架可對各功能模塊逐一 “體檢”，保障修改后的代碼質量過硬。    

當跨數據庫兼容性成為企業剛需，應用側處理更是當仁不讓。倘若業務邏輯扎根于數據庫中，遷移成本將如雪球般越滾越大。反之，將業務邏輯封裝于應用程序代碼，開發人員只需著力適配數據庫連接驅動，微調少量數據訪問層代碼，即可低成本實現平穩過渡。

不過，在性能至上的領域，數據庫的存儲過程和 SQL 則能夠發揮到極致。金融機構每日直面海量交易數據沖擊，如股票交易系統的實時行情剖析、銀行的批量轉賬清算業務。存儲過程在數據庫服務器本地 “發力”，大幅削減數據網絡傳輸的 “長途奔波”，緊密貼合數據庫查詢優化器、索引機制，實現數據的快速讀寫與復雜聚合運算，即便高并發、大數據量來襲，系統響應依舊穩如泰山。

涉及關鍵業務數據操作，存儲過程更是數據一致性與安全性的忠誠衛士。一些關鍵業務必須作為原子事務處理，借由數據庫強大的事務管理能力與 ACID 特性，確保操作準確穩定高效，杜絕數據不一致的 “定時炸彈”。對外僅露有限接口，將核心業務邏輯深藏其中，讓外部惡意攻擊、非法篡改無機可乘。

對于成本敏感的企業建設IT系統時，簡單的中間件+數據庫+存儲過程架構也可以大大節約系統建設成本，避免了復雜的前端應用架構。

傳統企業抉擇系統架構的時候，應道立足當下業務痛點，以未來發展藍圖為指引，審慎掂量應用側與數據庫存儲過程的長短板，讓技術架構精準賦能企業運營，如此才能多快好省地建設IT系統。

各位讀者，今天的文章是不是讀著有點費勁？因為這篇文章是我和豆包聊天后生成的。我讀了以后，對今后退休后碼碼字賺點零花錢又多了幾分信心，因為前幾天有朋友和我說，豆包寫作已經秒殺人類了。說那話的哥們寫作水平一定很爛。豆包寫出來的東西雖然通順，但是不大像是人說的話。 

接下來用我自己的語氣來繼續這個話題，這句話可以翻譯為 “數據庫就是業務架構”。從某種特定角度理解其合理性：

從數據驅動的業務視角看，在現代企業中，業務架構很大程度上依賴于數據。數據庫存儲了業務運作所需的各種關鍵信息，例如客戶數據（包括客戶的基本信息、購買歷史、偏好等）、產品數據（產品規格、庫存數量、價格等）以及交易數據（訂單信息、支付記錄等）。

從系統集成的角度看，企業通常會有多個不同的系統，如客戶關系管理系統（CRM）、企業資源規劃系統（ERP）等。這些系統之間的集成往往是通過數據庫來實現的。

不過這句話也有不完全準確的方面。首先業務架構還有其他的要素，業務架構不僅僅包括數據庫。它還涉及到業務流程、組織架構、業務規則等多個方面。業務流程定義了工作的順序和方式，組織架構確定了人員的職責和分工，業務規則則規定了業務操作的準則。

在戰略和目標層面，業務架構還需要考慮企業的戰略和業務目標。企業的戰略決策會影響業務架構的設計，例如企業決定開拓新的市場或推出新的產品服務線，這會導致業務架構的調整。數據庫雖然可以支持這些戰略變化，但它本身不是戰略的制定者，也不能完全體現企業在戰略和目標層面上的業務架構考慮。比如，企業的戰略是要提供高端個性化的服務，這就需要在業務架構中考慮如何設計服務流程、組織相應的專業服務團隊等，而數據庫只是記錄和輔助這些過程中產生的數據。

在業務全面數字化的趨勢下，數據庫的設計可以越來越緊密地與業務流程相結合。隨著數據治理的重要性日益凸顯，數據庫可以成為承載業務規則的載體。數據服務與業務功能也可以深度融合，數據庫可以提供豐富的數據服務，這些服務能夠直接支持業務功能的實現。

二者相融合后會有以下的優勢：首先是提高業務敏捷性，當數據庫與業務架構融合后，企業能夠更快速地響應市場變化，因為數據庫和業務架構的融合使得數據到業務決策再到業務行動的鏈路更短，減少了中間環節的信息損耗和延遲。

其次是增強數據一致性和準確性，在融合的環境下，業務規則在數據庫中得以實施，確保了數據的生成和更新符合業務要求，數據庫能夠準確地更新信息，避免了數據不一致的情況，提高了數據的準確性，從而為整個業務提供更可靠的數據支持。

第三是優化資源配置，融合后的數據庫能夠更好地反映業務架構中的資源需求和使用情況。企業可以合理安排設備維護時間，避免生產中斷，提高資源利用效率。

關于今天寫的這個問題，其實在幾年前我和一個搞業務的老專家交流過，他就提出了數模與業務模型脫節的問題，他當時問我能不能不使用數據庫為中心，而是以業務模型為中心來構建信息系統，一切都圍繞業務建模。當時我覺得他這個想法有點過于理想化，實現起來難度很大，因為業務是在不斷變化的，動態的數據模型會讓應用無法穩定演進。其實這個想法未必不能實現，前提條件是數據庫要具備十分強大的多模融合能力和AI算法能力。這似乎也是數據庫技術正在奮斗的方向。