前言關(guān)系型數(shù)據(jù)庫依然是有史以來最成功的技術(shù)之一。多年來，關(guān)系型數(shù)據(jù)庫面臨了諸多挑戰(zhàn)。例如，在20 世紀90 年代末出現(xiàn)的面向?qū)ο蟮臄?shù)據(jù)庫曾有望取代占據(jù)主導(dǎo)地位的關(guān)系模型。將近四分之一個世紀后，關(guān)系型系統(tǒng)依然處于強勢地位，這種屹立不倒的背后有很多因素。最近加入戰(zhàn)場的挑戰(zhàn)者中包括NoSQL 產(chǎn)品，比如MongoDB。不過出于多種原因，關(guān)系型數(shù)據(jù)庫在IT 領(lǐng)域中繼續(xù)保持著顯著地位。扎實掌握Oracle、IBM、Microsoft 等公司的關(guān)系型數(shù)據(jù)庫，仍然是IT 技能組合中的加分項。開源關(guān)系型數(shù)據(jù)庫也不例外，比如MySQL。我從事過的所有開發(fā)者工作幾乎都要求至少具備一定程度的SQL 知識。有些工作還要求懂得PL/SQL等存儲過程語言。正如你將在本書中看到的，人們對于SQL 和PL/SQL 在高級語言（Java、C#、JavaScript 等）中的角色常常存在很大的困惑。我對多語言領(lǐng)域中存在的一些常見的反模式作了討論。由于種種原因，相較于PL/SQL，用戶往往有強烈的意愿選擇完全基于嵌入式SQL 和對象關(guān)系映射的解決方案，這可能會導(dǎo)致不經(jīng)意間使用反模式，從而產(chǎn)生脆弱的代碼。我仔細研究了Oracle PL/SQL，希望能夠為創(chuàng)建彈性數(shù)據(jù)庫解決方案奠定良好的基礎(chǔ)。在我們這個日益以數(shù)據(jù)為主導(dǎo)、以數(shù)據(jù)為中心的世界，對彈性系統(tǒng)的需求從未如此迫切。本書適合的讀者如果你對學(xué)習數(shù)據(jù)庫和PL/SQL 感興趣，這本書是一個不錯的入手點。本書采用了從第一性原理的方法，因此不需要太多的基礎(chǔ)知識。我們重點關(guān)注的是PL/SQL 中的良好實踐，并使用需求分析和指標來幫助各種技術(shù)水平的讀者。那些涉及多種語言（比如Java、JavaScript、C# 等）的組織員工會發(fā)現(xiàn)這本書的價值。這類組織通常也使用一種或多種數(shù)據(jù)庫技術(shù)，其中就包括PL/SQL。盡管他們的系統(tǒng)每天都在運行 PL/SQL，但開發(fā)人員不一定只使用PL/SQL。也就是說，PL/SQL 并不是主力開發(fā)語言。由于PL/SQL 用得不多，開發(fā)人員在語言構(gòu)件和抽象方面未必懂得最佳解決方案。結(jié)果往往令人失望，更別提什么彈性了。這也增加了DevOps 成本，而且改善的希望渺茫。后者甚至可能因為Oracle 產(chǎn)品中自主技術(shù)的出現(xiàn)而加劇。換句話說，Oracle 轉(zhuǎn)向自主機制的做法可能會產(chǎn)生令人尷尬的效果，使一些拙劣的數(shù)據(jù)庫解決方案成為焦點。我相信本書能為第一次接觸PL/SQL 的用戶以及有經(jīng)驗的PL/SQL 開發(fā)人員帶去不少幫助。除了批處理風格（batch-style）的PL/SQL 解決方案外，我還探討了在Java 內(nèi)調(diào)用PL/SQL 這一棘手的問題。面向需求在整本書中，我嘗試制定簡單廣泛的設(shè)計和編碼需求。在深入探討實現(xiàn)細節(jié)之前，先闡明這些需求，這為后續(xù)代碼提供了藍圖，也是指導(dǎo)編碼過程的一種良好的通用做法。闡明良好的需求是軟件開發(fā)中一項強大的技能，這有助于任何語言的編程，而不僅僅局限于 PL/SQL。正如我過去在寫作中經(jīng)常提到的，需求分析和設(shè)計是扎實編碼的必要前提。有句老話說得好：編碼越早，項目越久。這句話適用于過去，也同樣適用于今天。本書中的一些需求導(dǎo)向可以視為非功能性需求。也就是說，這些需求不是針對特定業(yè)務(wù)問題或功能變化的。相反，這里描述的彈性需求是創(chuàng)建整體彈性解決方案的指南。邁向策略性編碼在眾多行業(yè)從事IT 工作多年的過程中，我認為現(xiàn)代編碼大多是戰(zhàn)術(shù)性的。很多組織的需求清單都很長，實際上根本無法實現(xiàn)。這對于底層業(yè)務(wù)是一個相當嚴重的威脅，因為底層業(yè)務(wù)的正常運行依賴于這些新的或改動過的功能。在缺乏完善流程的情況下，救火隊員似的編碼方式很容易成為常態(tài)。這種模型鮮少是可持續(xù)的，甚至可能導(dǎo)致過高的開發(fā)人員流動率，從而進一步加劇問題。采用更注重需求的思維模式能夠?qū)崿F(xiàn)更具策略性的編碼方法。在PL/SQL 代碼示例中，我旨在展示這種工作模式。策略性編碼的一個關(guān)鍵方面是接受某些非功能性需求。我們會看到，這種例子包括為可觀測性和可修改性進行編碼。除此之外，策略性編碼風格還包括簡單性、模塊化和其他特性。代碼的簡單性為什么重要？要回答這個問題，只需看看平均代碼庫（average codebase）。如今，大多數(shù)代碼庫都至少包含一種主流框架。我在2007 年左右第一次開始使用像Spring 這樣的框架，當時就被其復(fù)雜性震住了。這只是我的一家之言，但我相信這個框架最終會變得非常復(fù)雜，必須作為Spring Boot（我也使用過）的一部分進行大幅修改。然而，Spring Boot 試圖隱藏舊Spring 的許多復(fù)雜性。在我曾參與過的Spring Boot 項目中，集成還需要調(diào)試框架本身。這并不適合簡單的編碼，往往需要一組開發(fā)人員共同嘗試各種方案，才能讓代碼正常工作。這跟簡單性完全不沾邊。作為策略性PL/SQL 編碼風格的一部分，第Ⅱ部分和第Ⅲ部分介紹了作為系統(tǒng)能力宏觀建模手段的特性驅(qū)動開發(fā)。我認為，特性驅(qū)動開發(fā)可作為一種開展彈性編碼的方法。彈性軟件是過程，不是目的每一個新需求及其相關(guān)代碼都會對整體解決方案的彈性產(chǎn)生影響。彈性軟件不是你想要就能有的。我們不能只是說要確保這個新特性具有彈性。怎么就不能呢？因為我們還不知道什么是彈性以及如何將其應(yīng)用于我們的代碼。為了解決這些復(fù)雜的問題，本書首先仔細描述了何為彈性。即使是最大的萬億級公司也在竭力編寫彈性代碼。難點在于，彈性通常是根據(jù)多個軟件系統(tǒng)在承壓期間互動的成功程度來判斷的。因此，如果系統(tǒng)X 具有彈性，系統(tǒng)Y 不具有彈性，那么整個系統(tǒng)（X Y）很可能沒有彈性。大型企業(yè)實體的災(zāi)難恢復(fù)周期時間目前（2023 年）在45 分鐘以內(nèi)。即便是在系統(tǒng)功能受限或損壞，上游或下游系統(tǒng)暫時不可用的情況下，要讓代碼恢復(fù)正常運行，這些時間也并不充裕。為了緩解彈性定義的難題，我引入了彈性尺度。這是一組簡單的規(guī)則，可用于指導(dǎo)設(shè)計和編碼工作。我們的目標是消除以下五種常見反模式：? 復(fù)雜性。? 脆弱的代碼。? 代碼的未來維護成本。? 性能低下。? 關(guān)注點分離不良。這聽起來口氣不��！我們怎么樣解決這些反模式？為此，需要某種彈性尺度：1. 能夠捕獲所有錯誤和異常。2. 可恢復(fù)性。3. 可觀測性。4. 可修改性。5. 模塊化。6. 簡單性。7. 編碼規(guī)范。8. 可復(fù)用性。9. 可重復(fù)測試。10. 避免常見的反模式。11. 模式（schema）演進。那么，什么是彈性尺度呢？彈性尺度我引入了一種用數(shù)值表示數(shù)據(jù)庫解決方案彈性的尺度。雖然純粹是經(jīng)驗性的，但這種尺度說明了PL/SQL 的脆弱用法與更具彈性的方法之間的區(qū)別。通過提高某個PL/SQL 塊的得分，代碼就會變得更有彈性。迭代地使用該尺度可以幫助你找到一種強有力的PL/SQL 重構(gòu)方法。讓PL/SQL 解決方案更具彈性的還有其他原因。例如，Oracle 正在不斷引入其他技術(shù)來提高其產(chǎn)品的內(nèi)在彈性。這種例子還包括（但不限于）：? 自愈元素。? 自主數(shù)據(jù)庫技術(shù)? 避免超量使用CPU、網(wǎng)絡(luò)、內(nèi)存。在編寫PL/SQL 代碼時注重彈性設(shè)計，就是在某種程度上與Oracle 在這一領(lǐng)域的努力保持同步。這使得你的代碼在由這些Oracle 產(chǎn)品構(gòu)建的系統(tǒng)中成為更好的一員。你的彈性代碼將更輕松地融入愈發(fā)彈性化的Oracle 生態(tài)系統(tǒng)中。彈性解決方案和災(zāi)難恢復(fù)在我們這個日益互聯(lián)的世界中，IT 災(zāi)難是不幸的生活現(xiàn)實。停機是常有的事。衡量一個企業(yè)IT 質(zhì)量的方面之一就是其從災(zāi)難中恢復(fù)的速度。例如，數(shù)據(jù)中心因某種原因離線，會給企業(yè)造成重大服務(wù)損失。這是彈性的宏觀層面。大型組織會因故障而蒙受巨大損失，這可能是財務(wù)損失和/ 或聲譽損失。無論是哪種情況，許多此類組織都會制定災(zāi)難恢復(fù)目標，比如每年允許x 分鐘的停機時間。即使對于大型企業(yè)來說，x 的值也低得出奇。在災(zāi)難恢復(fù)期間，讓代碼快速恢復(fù)運行非常重要。重要的是要認識到，不能讓你的代碼對x 值產(chǎn)生負面影響。例如，如果你的代碼在中斷恢復(fù)后無法運行，那么為追蹤問題而建立足夠的源代碼日志記錄則至關(guān)重要。尤其是當問題出現(xiàn)在你無法直接控制的下游或上游的依賴系統(tǒng)中時，更是如此。要是日志記錄為提供了問題根源的可靠線索，在停機修復(fù)期間，你的同事絕對會感謝你給出的這些信息。每一行代碼都會對組織的整體彈性產(chǎn)生積極或消極的影響。這屬于彈性的微觀層面。雖然這是一個廣闊的領(lǐng)域，值得另寫一本書，但我將深入探討編寫彈性PL/SQL 的主題及其在幫助整個組織產(chǎn)生彈性解決方案方面的重要性。以圖表驅(qū)動的敘述方式我堅信圖表在清晰描述思路和代碼工作流方面的巨大作用。本書大量使用屏幕截圖來說明所述代碼的實際運行情況。我希望這種敘述風格能對讀者有所幫助。使用示例代碼本書示例代碼和練習等補充材料可從https://github.com/stephenbjm/plsql-resilience下載。如果你有技術(shù)疑問或在使用示例代碼時遇到問題，請發(fā)送電子郵件至 errata@oreilly.com.cn。本書旨在幫助你完成工作。一般來說，你可以在自己的程序或文檔中使用本書提供的示例代碼。除非需要復(fù)制大量代碼，否則無需聯(lián)系我們獲得許可。例如，使用本書中的一些代碼片段編寫程序不用獲得許可，銷售或分發(fā)OReilly 圖書的示例光盤則需要獲得許可。引用本書中的示例代碼回答問題不用獲得許可，將本書中的大量示例代碼放到產(chǎn)品文檔中則需要獲得許可。我們感謝但并不強制要求你在引用本書內(nèi)容時標注出處。出處說明通常包括書名、作者、出版社和ISBN，例如：Resilient Oracle PL/SQL by Stephen B. Morris(OReilly). Copyright 2023 Omey Communications Limited, 978-1-098-13411-2。如果你覺得自己對示例代碼的用途超出了上述許可的范圍， 歡迎通過permissions@oreilly.com 與我們聯(lián)系。法律聲明所有來自O(shè)racle 產(chǎn)品（如SQL Developer 等）的截圖受以下Oracle 聲明的約束：Copyright ? Oracle 及其關(guān)聯(lián)公司。已獲授權(quán)使用。第三部分使用的SQL 腳本取自GitHub，網(wǎng)址為 https://github.com/oracle-samples/db-sample-schemas，受以下Oracle 聲明的約束：Copyright ? 2019 Oracle。IntelliJ IDEA 的截圖受以下聲明的約束：Copyright ? 2022 JetBrains s.r.o.，已獲授權(quán)使用。JetBrains IntelliJ IDEA 和IDEA 的logo 是JetBrains s.r.o. 的注冊商標。OReilly 在線學(xué)習平臺（OReilly Online Learning）近40 年來，OReilly Media 致力于提供技術(shù)和商業(yè)培訓(xùn)、知識和卓越見解，來幫助眾多公司取得成功。公司獨有的專家和改革創(chuàng)新者網(wǎng)絡(luò)通過OReilly 書籍、文章以及在線學(xué)習平臺，分享他們的專業(yè)知識和實踐經(jīng)驗。OReilly 在線學(xué)習平臺按照您的需要提供實時培訓(xùn)課程、深入學(xué)習渠道、交互式編程環(huán)境以及來自O(shè)Reilly 和其他200 多家出版商的大量書籍與視頻資料。更多信息，請訪問網(wǎng)站：https://www.oreilly.com/。聯(lián)系我們?nèi)魏斡嘘P(guān)本書的意見或疑問，請按照以下地址聯(lián)系出版社。美國：OReilly Media, Inc.1005 Gravenstein Highway NorthSebastopol, CA 95472中國：北京市西城區(qū)西直門南大街2 號成銘大廈C 座807 室（100035）奧萊利技術(shù)咨詢（北京）有限公司OReilly 的每一本書都有專屬網(wǎng)頁，你可以在那兒找到本書的相關(guān)信息，包括勘誤表、示例代碼以及其他信息。本書的網(wǎng)頁位于https://oreil.ly/resilient-oracle-plsql。要了解更多 OReilly 圖書、培訓(xùn)課程和新聞，請訪問https://oreilly.com。我們的Facebook：http://facebook.com/oreilly。我們的Twitter：http://twitter.com/oreillymedia。我們的Youtube：http://youtube.com/oreillymedia。致謝我的編輯Corbin Collins 指導(dǎo)了這個項目，并在許多棘手問題上為我提供了建議，比如如何以不同的方式處理本書的印刷版和電子版的鏈接。謝謝你，Corbin ！在寫作階段，我很高興與Kristen Brown、Katherine Tozer、Catherine Dullea 合作。Katie 和Kate 用務(wù)實的創(chuàng)造力和良好的判斷力把我的圖表整理得井井有條。在此期間，我還學(xué)到了很多關(guān)于圖像分辨率和印刷尺寸的知識！謝謝你們，Kristen、Katie、Kate。我還要向Karen Montgomery 致以深深的謝意，感謝她漂亮的封面插圖。Andy Kwan 是我與OReilly 的第一位聯(lián)系人，他從一開始就堅信這本書的價值。特別要感謝Patrick Barel，他對每一章都做了深入的技術(shù)審查。Patrick 指出了一些關(guān)鍵的編碼錯誤和不少技術(shù)問題。多謝你分享的知識和經(jīng)驗，Patrick。Michael McLaughlin（獲得了Oracle Ace Pro 認證）也給出了有益的技術(shù)反饋。謝謝你，Michael，感謝你對SQL Developer 的處理方式和功能描述的深思。最后，同樣的感謝要送給技術(shù)審查團隊的Sayan Malakshinov。Sayan 提供的反饋既出色又飛快，為本書加入了很多有用的補充。我要向Mark Schreier 和他在Oracle Trademark & Copyright Legal Group 的團隊表達我的感激之情，謝謝他們允許我使用Oracle 擁有的屏幕截圖。獲得許可的請求秒速通過。還要感謝Oracle Global Communications 的Travis Anderson，是他幫我聯(lián)系到了Mark 的團隊。網(wǎng)絡(luò)的魔力使我在撰寫本書第Ⅲ部分時結(jié)識了Ben Brumm。Ben 慷慨的允許我使用他優(yōu)秀的SQL 腳本來安裝Oracle HR 模式。