SQL VS NoSQL 如何選擇資料庫

2022-09-07 08:48:13 字數 2813 閱讀 6464

首先我們先來總結一下:

sql資料庫:

nosql資料庫:

sql資料庫適合那些需求確定和對資料完整性要去嚴格的專案。nosql資料庫適用於那些對速度和可擴充套件性比較看重的那些不相關的,不確定和不斷發展的需求。簡單來說就是:

很少有專案能夠很好的適用於一種資料庫。如果你對資料的需求比較小或是非標準化的資料任何一種資料庫都是可以的。你比我更了解你的專案,我不建議你將sql上的資料移植到nosql上反之亦然,除非它能夠提供非常可觀的收益。當然選擇權在於你自己。在專案的一開始就要考慮好使用它們的利弊,這樣才不會導致選擇錯誤。

我們來重新的定義操作並基於sql實現通訊錄系統。我們初始簡單的定義contact表擁有如下幾個字段;

問題一:

很少有人只擁有乙個手機號。或許我們可以再新增三個字段:固定**,移動**和工作**,但是無論我們給乙個聯絡人分配了多少個字段總會有人需要更多。我們需要建立乙個單獨的telephone表,這樣就可以給乙個聯絡人存多個號碼了。這樣也就規範化了我們的資料— 我們不需要乙個沒有**的聯絡人:

問題二:

對於聯絡人郵箱我們也會遇到上述問題,因此我們也需要建立乙個email的表:

問題三:

我們在填寫聯絡人資訊是我們並不希望填寫他的地理位置,或者我們想記錄他工作、生活、旅遊的地方等。因此我們需要乙個address表:

我們原先設計的contact表就精簡為:

好了,我們已經設計了乙個規範化的資料庫,可以用來儲存任何乙個聯絡人的**號碼,郵箱位址和住址了。但是......

模式是固定不變的

我們並沒有考慮到聯絡人的生日,公司或者職位。不管我們新增多少個字段,我們會得到更多的需求:備註,周年紀念日,關係,社交賬號,喜歡巧克力的種類等等。**每乙個需求對於我們來說是非常困難的,因此我們需要建立一張表其中儲存的形式是鍵值對來應對不斷增加的需求。

資料是碎片化的

對於開發人員和系統管理員來說不斷地檢查資料庫是比較麻煩的。程式的邏輯會變得更複雜效率更慢,因為使用一條select語句來join多個表來取出乙個聯絡人的全部資訊不太實際。(當然這也是可以實現的,但是當乙個聯絡人中國包含**號碼,郵件位址和住址資訊時:如果乙個人有3個**號碼,五個郵箱和兩個住址,那麼sql查詢會產生30個結果,也就是說說這樣的效率會很慢。)

最後,全文搜尋是非常困難的。如果乙個人要查詢乙個字元型:f**orite,我們需要依次查詢上述的四張表判斷是否是乙個聯絡人的姓名,**,郵件或者位址依據這些把結果進行排序。如果你使用過wordpress的搜尋,你就會發現是都麼的煩人了!

我們的聯絡人關注的是人這個實體。然而關於人的資訊是不可**的並且在不同的階段的需求也會不一樣。如果我們使用nosql資料庫會比較方便,nosql將乙個人的資訊儲存為乙個文件並放入contacts的集合中:

在這個示例中,我們沒有儲存這個人的性別和職銜,並且可以新增一些別的聯絡人沒用的資訊。在nosql中這樣的儲存是合法的,並且我們可以按照各人的意願來新增和刪除乙個字段。

因為乙個聯絡人儲存在乙個文件中,因此我們可以使用乙個查詢語句取出乙個人的所有資訊。對於全文搜尋,在mongodb中我們可以在contact的字段中定義乙個索引:

db.contact.createindex();

然後我們就可以使用如下的語句進行全文搜尋:

db.contact.find(

});

場景二:社交網路

乙個典型的社交網路使用的聯絡人的資訊是相似,但是也會增加一些新的功能例如:社交網路,狀態更新,私信和點讚。這些功能會根據使用者的需求進行新增或者刪除,**使用者的需求對開發人員來說是非常困難的。

另外:因此,nosql是乙個不錯的選擇。資料庫允許我們儲存不同型別的資料以便於我們快速的開發出新的功能。例如,因為所有的資料狀態的更新都可以在status的集合中的乙個文件中進行:

,

]}

儘管對於這個文件來說資料會變得多一些,但是我們可以僅僅取出文件的乙個子集,例如:最新的狀態等。對於每乙個使用者來說歷史記錄也會很容易搜尋的到。

資料需求:

儲存貨物的基本資訊例如:尺寸、大小、顏色等,這些不相關的資料我們要能夠用到任何的貨物上。我們不可能去考慮一些貨物個性化的資訊例如:筆記本處理器的速度或者是一部手機電池的壽命。

我們要盡可能的避免錯誤的發生。我們不能讓貨物憑空消失或者將貨物存放到已經存放貨物的位置上去。

以更加簡單的方式操作。我們記錄將一件貨物從乙個位置移動到另乙個位置或者從a移動到b的操作是相同的。

因此,我們需要考慮對資料的完整性和對於事務的支援。目前來說也就是sql能夠很好地滿足我們的需求。

我希望上述的案例能夠對你有一定的幫助,但是每乙個實際的專案都是不同的,對一無二的你需要自己去做決定選擇一種適合的。(儘管,對於我們開發人員來說我們不太願意去改變我們現有的選擇,無論新的技術有多好!o(∩_∩)o)

mysql選擇產品和功能 如何選擇合適的資料庫產品

當今市面上的資料庫產品眾多,如何選擇mysql,redis,或者是mongodb 以下從資料庫的讀寫資料和查詢資料,以及使用場景上,分別對這幾種資料庫進行比較 1 redis,mongodb,mysql 在讀寫資料的區別 資料主要涉及讀和寫的兩個問題,出於效能的考慮,當然希望讀和寫的速度越快越好 計...

如何選擇網域名稱

一系列的事件讓人們對cn網域名稱投資興致盎然,然而,網域名稱如何註冊?好網域名稱如何起?記者經過多方探訪,總結出cn網域名稱投資的 實用手冊 好網域名稱如何評估 網域名稱的最終價值體現在它是否能帶來流量和利潤,這些結果都將決定你的未來買家願意出多少錢來購買你的網域名稱。所以,衡量乙個網域名稱價值標準...

如何選擇集合

在程式設計的過程中,選擇何種集合至關重要,下面由我來總結下選擇集合的方法 選擇集合所考慮的關鍵問題在於 效率代價與空間代價的平衡問題。效率代價是指執行的效率,簡單的說如果乙個資源沒有把索引記錄下來,那麼要找到他你就需要執行程式,那麼你的代價在於系統花錢了時間。空間代價是指存放的空間消耗記憶體的代價,...