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

圖片

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

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

當跨數(shù)據(jù)庫兼容性成為企業(yè)剛需，應(yīng)用側(cè)處理更是當仁不讓。倘若業(yè)務(wù)邏輯扎根于數(shù)據(jù)庫中，遷移成本將如雪球般越滾越大。反之，將業(yè)務(wù)邏輯封裝于應(yīng)用程序代碼，開發(fā)人員只需著力適配數(shù)據(jù)庫連接驅(qū)動，微調(diào)少量數(shù)據(jù)訪問層代碼，即可低成本實現(xiàn)平穩(wěn)過渡。

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

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

對于成本敏感的企業(yè)建設(shè)IT系統(tǒng)時，簡單的中間件+數(shù)據(jù)庫+存儲過程架構(gòu)也可以大大節(jié)約系統(tǒng)建設(shè)成本，避免了復(fù)雜的前端應(yīng)用架構(gòu)。

傳統(tǒng)企業(yè)抉擇系統(tǒng)架構(gòu)的時候，應(yīng)道立足當下業(yè)務(wù)痛點，以未來發(fā)展藍圖為指引，審慎掂量應(yīng)用側(cè)與數(shù)據(jù)庫存儲過程的長短板，讓技術(shù)架構(gòu)精準賦能企業(yè)運營，如此才能多快好省地建設(shè)IT系統(tǒng)。

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

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

從數(shù)據(jù)驅(qū)動的業(yè)務(wù)視角看，在現(xiàn)代企業(yè)中，業(yè)務(wù)架構(gòu)很大程度上依賴于數(shù)據(jù)。數(shù)據(jù)庫存儲了業(yè)務(wù)運作所需的各種關(guān)鍵信息，例如客戶數(shù)據(jù)（包括客戶的基本信息、購買歷史、偏好等）、產(chǎn)品數(shù)據(jù)（產(chǎn)品規(guī)格、庫存數(shù)量、價格等）以及交易數(shù)據(jù)（訂單信息、支付記錄等）。

從系統(tǒng)集成的角度看，企業(yè)通常會有多個不同的系統(tǒng)，如客戶關(guān)系管理系統(tǒng)（CRM）、企業(yè)資源規(guī)劃系統(tǒng)（ERP）等。這些系統(tǒng)之間的集成往往是通過數(shù)據(jù)庫來實現(xiàn)的。

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

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

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

二者相融合后會有以下的優(yōu)勢：首先是提高業(yè)務(wù)敏捷性，當數(shù)據(jù)庫與業(yè)務(wù)架構(gòu)融合后，企業(yè)能夠更快速地響應(yīng)市場變化，因為數(shù)據(jù)庫和業(yè)務(wù)架構(gòu)的融合使得數(shù)據(jù)到業(yè)務(wù)決策再到業(yè)務(wù)行動的鏈路更短，減少了中間環(huán)節(jié)的信息損耗和延遲。

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

第三是優(yōu)化資源配置，融合后的數(shù)據(jù)庫能夠更好地反映業(yè)務(wù)架構(gòu)中的資源需求和使用情況。企業(yè)可以合理安排設(shè)備維護時間，避免生產(chǎn)中斷，提高資源利用效率。

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