相信很多開發者都有個疑問，如果以一種簡單、靈活的方法來儲存程式資料，應該選擇nosql還是sql呢？
nosql資料庫提供了非常完美的體驗：乙個安裝包，啟動資料庫，使用json api進行資料讀寫操作。此外，nosql支援快速迭代。
sql方案需要更多的預先投資：配置伺服器，插入資料，設定資料表，以物件關係對映系統來進行資料獲取。
兩者對比權衡，創業公司更青睞nosql。那麼要擁抱nosql，需要經歷哪些階段呢？
階段一：排除
決定使用nosql便意味著你做出了兩個重要決定：無需acid事務和無需乙個架構。這看起來是無害的，但是其結果會對程式產生深遠影響。
排除的第一種形式是你不需要acid事務。這在應用的早期階段常見，但是隨著使用者規模增長，事務處理的邏輯能力將會使你的程式更易於運作。所以完全放棄事務是不可取的。
排除的第二種形式是不需要架構。這意味著程式可以有效處理資料間的邏輯，而無需借助傳統關係型資料庫的關係處理能力。
階段二：憤怒
nosql資料庫的設計目的是在分布式機器集群中取得連續性和可用性的平衡。因此，你不得不使用複雜的分布式演算法來進行協調，同步和錯誤處理。
某天當你發現資料丟失而憤怒不已時，將發現事務和架構是多麼重要。
階段三：商討
當憤怒消退後，或許你會嘗試把事務和架構補充回nosql中。首先是為應用程式編寫事務管理器。但是交易系統通常很龐雜，模組之間相互依賴，涉及到併發控制，錯誤恢復和許可權訪問。你可能會成功，但最終的結果將很難進行擴充套件或維護。
第二個方法是使用複雜組織條件和處理來增強資料整合，確保資料完整性。這些規則嵌入在應用程式邏輯並需要傳達給每個使用該資料庫的開發團隊。
階段四：沮喪
當為你找出乙個可行的事務處理方案和乙個臨時的架構處理方案時，你可能發現你的nosql不能很好地處理其它需求。它不能聯接表，不能對記錄進行分組，更不必說複雜的查詢。這時你會變得沮喪，試圖尋求集群運維專家的幫忙。
階段五：接受
看來nosql也有其不足之處。最後接受這個事實，你批判性地評估自己的資料庫解決方案。你試圖區分資料中哪些屬於關係型哪些不屬於關係型。最終，找出乙個使nosql和關係型資料庫友好共處的方案：擴充套件關係型滿足一部分需求，擴充套件nosql滿足另外一部分需求。
被**廣泛宣傳的新技術，必須經過個人實踐，找出適合自己的部分才是有價值的；否則，拔苗助長，生搬硬套只會徒增煩惱。
原文：the five stages of nosql作者：kevin sookocheff 翻譯：王嘉怡 責編：仲培藝
移動開發者如何擁抱AI大潮
前言 隨著人工智慧的迅速崛起，移動網際網路逐漸趨於飽和，很多移動網際網路從業者開始變得憂慮和彷徨 在ai時代的大肆碾壓下，我們到底是應該繼續堅守還是轉戰ai呢？這確實是乙個值得思考的問題，技術一直都在更新，作為一名網際網路從業者必須擁有超強的學習能力和職業規劃能力才能發展的更好，走的更遠。移動網際網...
優秀的開發者 vs 糟糕的開發者
優秀的開發者是乙個藝術家，乙個享受創作過程的工匠。糟糕的開發者只將自己當作負責產生 的碼農。優秀的開發者了解客戶的問題。糟糕的開發者只了解手頭的技術問題。優秀的開發者會不斷努力去理解 為什麼 然後去實現，同時能夠把握大局。糟糕的開發者專注於構建類 方法和配置檔案，而不理會大局。糟糕優秀的開發者了解產...
優秀的開發者 vs 差的開發者
如果你認為使用 優秀 和 差 來區分開發者不妥的話，也可以將這些看作是初級開發者和資深開發者之間的區別。但無論如何，多看看其他的優秀開發者 或資深開發者 是如何做的，對於自身技能 工作方式的提公升有很大的幫助。優秀的開發者是乙個藝術家，乙個享受創作過程的工匠。差的開發者只將自己當作負責產生 的碼農。...