最近在數據庫領域內，出來了一個爆炸性的新聞。有專家提出了NoSQL的開源項目。簡單的說，就是他們要推翻原先的關係型數據庫的模型，設計一個不需要SQL語句的數據庫系統。筆者對此是採取反對的態度，或者說是在近期內不看好其前景。
一、NoSQL項目提出的背景。
NoSQL的支持者喜歡這個NoSQL項目，主要是看其在性能上的優勢。NoSQL支持者稱，NoSQL技術可以打破傳統關係型數據庫的性能瓶 頸。如通過NoSQL架構可以省去將Web或者Java 應用和數據轉換成SQL友好格式的時間，減少SQL語句解析與優化的時間，讓應用程序的速度變得更加快捷。
確實基於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項目這場數據庫革命仍然需要等待。在短時間內，無法跟關係型數據庫相互抗衡，也許永遠沒有這個機會。
