，為了方便本人閱讀，文字格式略有調整。
一、nosql專案提出的背景。
確實基於sql的關係型資料庫，在效能上確實存在一些瓶頸。但是這大部分並不是這個門sql技術所造成的。而是因為在設計資料庫的時候，表與表之間的關係、表的索引或者表空間的部署等等沒有設計好做造成的。所以關係型資料庫效能不理想，並不能全部怪罪到這麼技術上。通常情況下，對原有的資料庫設計進行優化，往往可以在很大程度上提公升資料庫的效能。所以說，nosql這個專案的背景是站不住腳的。
二、nosql革命仍然需等待。
根據目前的情況來看，筆者對於nosql專案的前景並不是很看好。或者說，對其前途感到很悲觀。nosql專案很難跟傳統的關係型資料庫相抗衡。甚至其想達到mysql這個開源資料庫的高度都很難。
1、 nosql很難實現資料的完整性。
當nosql這個專案開始以來，筆者也適當的關注過。但是筆者了解了這個專案後，對它的印象並不是很好。因為根據筆者的了解，很多關係型資料庫中優秀的、實用的功能，在nosql資料庫卻無法實現。如在任何乙個關係型的資料庫中，都可以很容易的實現資料的完整性。如在oracle資料庫中，可以輕而易舉的實現實體完整性(通過主鍵或者非空約束來實現)、參照完整性(通過主鍵、外來鍵來實現)、使用者定於完整性(通過約束或者觸發器來實現)。通過這些機制，可以實現資料的完整性。如可以設定某錶中某乙個列的值是唯一的而且不能夠為空。或者說在某錶中引用外來鍵的話，在另一張表中這個值必須存在。無論在刪除或者更新的時候，都必須存在。
nosql支持者也承認關係型資料庫在資料完整性上的作用是不可替代的。但是他們卻反駁說，企業可能用不到這麼複雜的功能。對於這一點筆者不敢認同。現在企業的任何乙個應用，基本上都需要用到資料完整性。如現在大部分應用至少都需要有乙個使用者認證的過程。為此在系統實現的過程中，需要在資料庫中儲存使用者名稱。由於這個使用者名稱涉及到使用者的認證問題，為此使用者名稱必須要唯一。此時就需要用到唯一性約束。在關係型資料庫中，只需要在**設計過程中，將使用者名稱設定為唯一即可。而在nosql中，還需要通過**來實現唯一性。本來很容易就可以實現，現在卻要繞個彎取實現，這有點不可思議。由於在nosql專案中很難實現資料的完整性，而在企業應用中這個資料完整性又是少不了的。為此筆者認為，nosql專案很難在企業中普及開來。至少在短時間內，nosql革命仍然需等待。
2、 缺乏強有力的技術支援。
到目前為止，nosql專案都是開源的。所以說他們缺乏**商技術人員提供的正式支援。在這一點，nosql專案與大多數的開源專案一樣，不得不從社群中尋求支援。但是，nosql專案比其他的開源專案要難得的多。首先nosql專案是乙個資料庫系統的專案。或者說，是一些網路應用的最基層的裝置。如果其出錯的話，後果很嚴重。由於缺乏正式的官方支援，萬一資料庫執行出現了錯誤，後果是很嚴重的。而且到時候使用者也是投訴無門的。所以，現在nosql專案基本上還是屬於研究的階段，如果要正式投入到企業中使用，被資料庫管理員所接受，至少其穩定性上要有所改善。或者說，當問題出現時，資料庫管理員要能夠及時修復執行故障。由於缺乏強有力的技術支援，資料庫管理員擔心故障出現時難以迅速解決，所以很多管理員都拒絕使用nosql專案，即使其是開源免費的。如nosql專案的組織者oskarsson也坦言，他們自己的公司現在使用的也不是nosql資料庫，甚至在短期內也沒有這個打算。他們現在使用的雖然是開源的資料庫系統，但是仍然是基於sql的關係型資料庫。像nosql專案的組織者都不敢輕易在企業中部署這個nosql資料庫，那麼其他資料庫管理員誰敢做第乙個吃螃蟹的英雄嗎?這不是拿自己的前途開玩笑。
3、 開源資料庫從出現到被使用者接受需要乙個漫長的過程。
假設這個nosql技術能夠被企業使用者所接受，但是從其出現到被使用者最終接受需要乙個漫長的過程。如mysql這個開源的資料庫系統，其從出現到流行也是花了好多年的時間。而且mysql資料庫是基於比較成熟的關聯式資料庫模型的。其在開發設計的時候，已經有不少完善的產品可以參考。至少sql語句的語法其可以直接拿來使用，而不用從零開始設計。而現在nosql是乙個從零開始的產品，所有內容都需要重新設計。在沒有**商技術人員的支援下，這個過程可能是很漫長的。即使退一萬步來說，最終其可以向mysql資料庫那樣受中小企業的歡迎，但是由於其自身技術的薄弱，在大型的資料庫應用中就會顯得心有餘而力不足。
4、 關係型資料庫在設計時更能夠體現實際。
其實關係型資料庫也是從非關係型資料庫公升級過來的。之所以現在大部分資料庫都是建立在關係型資料庫模型之上的，就說明了關係型資料庫存在的價值。筆者認為，關係型資料庫最大的價值就在於其設計方便。因為其資料庫物件之間的關係模型(如三正規化等等)對於資料庫設計時很有幫助的，其在很大程度上體現了業務的實際情況。如在設計乙個erp系統時，主鍵與外來鍵的關係可以反映出產品資訊表與採購訂單之間的關聯。這種關係是那麼發符合實際。而現在nosql專案想把這種關係剝離掉，那麼在資料庫設計的時候，必然會增加很多的麻煩，會增加資料庫的難度。最重要的是，這些資料庫物件之間的關係不僅僅是關係而已，其還是一種強有力的準則，對於所有的關係型資料庫管理員都會產生約束。這就說明，如果必須強制遵守這些規則。從而讓oracle資料庫的管理員經過簡短的學習之後，也能夠很快的掌握sqlserver資料庫的技術。因為其內部的準則是共同的。資料庫管理員只要學習其表現形式即可。這就好像學汽車。你只要拿出駕照，那麼什麼牌子的車都可以開。因為其資料庫物件的關係、執行模式等等都是固定的。但是nosql專案由於缺乏這種關係，所以基於nosql技術的不同產品之間，可能會存在很大的差異。這不僅在資料庫設計的時候會增加不少的難度。而且在維護的時候，也需要花費更多的時間與精力。
總之，照目前的情況來看，筆者對nosql專案的思路是反對的。至少在近期很難有像樣的nosql產品面世。nosql專案的組織者oskarsson也承認，nosql專案這場資料庫革命仍然需要等待。在短時間內，無法跟關係型資料庫相互抗衡，也許永遠沒有這個機會。
NOSQL非關聯式資料庫。
nosql not only sql，而不是no sql。nosql，泛指非關係型的資料庫。隨著網際網路 web2.0 的興起，傳統的關聯式資料庫在應付web2.0 特別是超大規模和高併發的 sns型別的web2.0純 動態 已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的資料庫則由於其本身...
關聯式資料庫還是NoSQL資料庫
在過去，我們只需要學習和使用一種資料庫技術，就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多，而供你選擇的免費版本就更加少了，所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代，我們發現關聯式資料庫在效能 擴充套件性 資料的快速備份和恢復 滿足...
關聯式資料庫還是NoSQL資料庫
在過去，我們只需要學習和使用一種資料庫技術，就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多，而供你選擇的免費版本就更加少了，所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代，我們發現關聯式資料庫在效能 擴充套件性 資料的快速備份和恢復 滿足...