數據模型驅動不僅可以建立有效的應用程序，也可以有效地修改以合并新的特性。他們是“real-world”問題的解決和軟件世界模仿現實世界的行為之間的橋梁。（是的，軟件可以創造奇跡，但如果不是追求更簡單生活沒有人需要這些軟件！）本文論述了NoSQL數據庫在現代的應用軟件發揮作用。
　　驅動力
　　在過去的幾年中，有一個巨大的轉變則是在應用程序開發平臺棧的選擇上。傳統的WAMP和LAMP被逐步淘汰，而MEAN、CEAN等逐漸發揮出優勢。這種轉變是有很多原因的。最根本的原因是對現代Web的期望。最近的預期是Web應用程序已經不僅僅是局限于信息的傳遞。今天我們在Web應用程序的交互中，信息處理和內容分析已成為了非常關鍵的部分。這也常被稱為Web 2.0。未來持續增長的智能設備和傳感器連接到互聯網，繼續利用越來越多的由應用程序用戶生成的數據來提供智能化的增值作用（也稱為Web 3.0）。
　　這種Web應用程序轉變的范例中需要豐富的數據。同時，使數據可供消費是同樣重要的，而且不可用數據怎樣阻礙了預期用戶體驗和應用程序的開發成為了另一個主題！但是，值得一提的是，大多數面向用戶的應用程序都需要從多個數據源（數據源）中消費和處理數據。作為一個極端的例子，一個旅游預訂網站可能需要依賴于多個航空公司的航班數據和票務，而信用卡處理來自另一個第三方，行程公布又從另一個地方…更不要說，他們還可能會導致用戶在社交媒體上分享他們的預訂經驗，從他們自己的Web應用程序中就像一個用戶的端到端體驗的一部分。
　　很好，我依然沒有把NoSQL的作用完全呈現給你。你或許仍然想知道NoSQL所有的作用。因此，讓我們繼續。不管怎樣，了解如下的變化是非常重要的。今天引導我們開始利用新的解決方案，這些解決方案在大多數情況被創造或者被開發，因為他們不僅非常依賴今天或者僅僅因為今天是可能的（對比指責以前的計算機革命）。
　　NoSQL允許復雜的結構
　　SQL數據庫是結構化的。但是，在處理應用程序需求時，由于字段范圍、外鍵關系、規范化技術等，他們會導致某種程度的缺陷。例如，一個客戶訂單對象往往是分成表頭和詳細類型的標準化表的結構。NoSQL，另一方面不僅可以處理在一個單一結構中的表頭和細節。所以，盡管數據模型的結構可能是復雜的，它支持建立接近一個 “真實世界”的實體。當然，，這種能力的成本是把數據完整性管理推到了程序應用層。
　　NoSQL與基于REST架構
　　如果您使用Web服務或API，碰巧你的API默認為JSON響應（如果不是，你應該嘗試）。NoSQL數據庫，如MongoDB和CouchDB是按JSON格式的存儲數據（稱為文檔）。這使編碼API響應比接收數組容易得多。采用更高等級的API導致高度集成的應用程序，NoSQL數據庫很適合在存儲方面，提供和消費信息。
　　NoSQL帶來可伸縮性
　　NoSQL數據庫設計的思想是拆分為多節點數據庫，從而提供了極大的可伸縮性特性。例如，MongoDB目前可以擴展到超過100個節點，這些節點可以分布在不同的數據中心或地方。許多NoSQL數據庫也已經開始支持多個節點數據分區，有助于選擇規模更大的數據集的計算資源，同時也減少了不必要的復制，從而減少數據重復可伸縮性的成本。
　　因此，SQL還是NoSQL？
　　這取決于應用程序和特定場景。不，這是真實的，因為有許多因素，如：
　　開發工具和技術可能不支持NoSQL的；首選供應商（首選戰略伙伴關系等許多原因）在您的公司中可能仍然是一個傳統的SQL數據庫；首選的數據庫供應商可能會提供一些在傳統的數據庫中有NoSQL-like的特性，可以滿足當前應用程序的需求；數據模型可能是這樣的，選擇真的沒有什么區別；你支持開源代碼（從一個企業支持的觀點）；你的同事（開發人員、測試人員等）可能還不熟練。
　　因此，為您的應用程序選擇什么樣的數據庫是一個架構層面的決定。因此，這篇文章絕不是來影響你選擇傾向的，但是它能提高了人們對NoSQL被廣泛接受的意識和突出NoSQL在現代應用程序中所起的作用。
　　結論
　　重要的是要了解如今的網絡應用程序，如何適應現代技術的期望。用需求、路線圖和來自用戶的期望（特別是直接用戶交互）來平衡NoSQL的趨勢是非常重要的。最后，記住–需要驅動數據模型和數據模型驅動來自于SQL或NoSQL的選擇。關于這點，沒有錯誤的答案，每個人都可以嘗試去解答！
?

普通下載普通下載

相關電子資料下載