一、sql和nosql資料庫的特點對比
sql 資料庫的特點:
在表中儲存相關聯的資料
在使用之前需要定義表的乙個模式
鼓勵標準化減少資料冗餘
支援從多個表中檢索相關資料表連線在乙個單一的命令
實現資料完整性規則
提供事務使兩個或兩個以上的成功或失敗的資料更改作為乙個原子單元
可以擴充套件(有一些努力)
使用乙個強宣告性語言查詢
提供足夠的支援,專業技能和工具。
nosql 資料庫的特點：
將相關聯的資料儲存在類似 json 格式，名稱-值
可以儲存沒有指定格式的資料
通常必須規範化，所以乙個專案的資訊包含在乙個文件裡
應該不需要連線（假設使用規範化的文件）
允許任何資料被儲存在任何時候任何地方，不需要驗證
保證更新乙個文件 - 但不是多個文件
提供出色的效能和可伸縮性
使用 json 資料物件查詢
是乙個新的、令人興奮的技術。
sql 資料庫是乙個理想的專案，確定好了需求和健壯的資料的完整性是至關重要的。nosql 資料庫是無關理想，不確定的或者不斷變化的資料需求 ，在速度和可伸縮性上更重要。
簡單的術語：
nosql 是模擬。它最適合無固定要求的組織資料。典型的使用案例是社交網路，客戶管理和網路分析系統。
二、場景案例
場景一:乙個聯絡人列表
讓我們重新發明輪子，實現乙個基於sql的通訊錄系統。我們最初接觸表的時候，天真的定義以下字段：
id (主鍵id)
title (標題)
firstname （姓）
lastname （名）
gender （性別）
telephone （**）
email （郵箱）
address1 （位址1）
address2 （位址2）
address3 （位址3）
city （城市）
region （區/縣）
country (國家)
問題一: 很少人只有乙個**號碼。我們可能需要至少三個號碼：乙個座機，乙個移動**，乙個工作**。但是有多少個號碼無關緊要——有些人、有些地方需要更多。讓我們建立乙個單獨的 telephone 表，這樣的話他們想要多少聯絡人都可以。這也讓我們的資料標準化了——我們不需要沒有號碼的聯絡人顯示為null。telephone 表的字段資訊如下：
contact_id
name (文字，例如座機號，工作手機等)
number
contact_id
name (text such as home email, work email, etc.)
address
contact_id
name (text such as home, office, etc.)
address1
address2
address3
city
region
zipcode
country
我們原來的 contact 表簡化成：
idtitle
firstname
lastname
gender
我們沒有考慮到聯絡人的中間名字、出生日期、公司或職位。我們新增多少欄位都沒關係，我們很快會收到更新的需求要新增備註、紀念日、關係狀態、社交**賬號、內腿測量值、最喜歡的乳酪型別等字段。**所有選項是不可能的，因此我們可能需要乙個 otherdata 表，用來處理名字-值對。
對開發者或者系統管理員來說，檢查資料庫並不容易。程式邏輯會變得更慢、更複雜，因為利用單個 select 和多個 join 語句查詢聯絡人資料不太實際。(你可以這麼做，但是結果可能需要包含 telephone，email，和 address欄位的每一種組合：如果有個聯絡人有三個**號碼，五個email位址和兩個住址，那麼sql查詢將會產生30條結果。) 最後，全文搜尋很困難。如果有人輸入字串」sitepoint」，我們必須檢查所有的表，看看它是否為聯絡人名字、**、email或者住址的一部分，並且需要做相應的排序。
那麼如果我們選擇nosql呢？
我們的聯絡人資料關注的是人。他們難以**，在不同的時間有不同的需求。使用nosql資料庫，聯絡人列表將會從中受益。資料庫將乙個聯絡人的所有資料儲存在乙個單獨的文件裡的contacts 集合裡。
在這個例子裡，我們沒有儲存聯絡人的頭銜或者性別，我們還新增了一些資料，而這些資料不需要應用到任何其他聯絡人。沒關係——我們的nosql資料庫不會介意，我們還可以隨意新增或移除字段。
由於聯絡人資料在單獨的文件裡，我們可以用一條查詢語句獲取一部分或全部資訊。全文搜尋也變得簡單；在mongodb裡，我們可以這樣定義 contact 中的所有文字欄位的索引：
db.contact.createindex};
然後執行全文搜尋：
db.contact.fond}}
場景二：社交網路
社交網路可能使用類似的聯絡人資料儲存，但是它會根據功能集合擴充套件，比如關係鏈、狀態更新、傳送訊息和」贊「。這些功能可能會根據使用者需求來實現或者移除——無法**它們會怎樣演進。
儘管有些使用者可能認為，狀態更新失敗不可能引起系統崩潰或經濟損失。應用程式的介面和效能比資料完整性優先順序更高。
nosql看來是個好的方案。它允許我們快速地實現儲存不同型別資料的功能。例如，可以用單個文件裡的 status 集合替換所有使用者的過時的狀態更新。文件可能會變得很長，但我們可以獲取陣列的子集，比如最近的更新。每個使用者的所有的歷史狀態記錄都能被快速搜尋到。
現在假設我們想在發布更新的時候引入表情符號選擇。這涉及到給 update 陣列裡的新記錄新增圖引用。不像 sql 儲存，沒必要把之前訊息裡的表情符號置為 null——我們的程式邏輯可以顯示預設或者沒有，如果沒有設定表情符號的話。
場景三：倉庫管理系統
考慮乙個監控倉庫貨物的系統。我們需要記錄：
送達倉庫並被分配到指定位置的物品
倉庫內物品的移動，也就是重新整理庫存，以便讓同樣的物品放在相鄰的位置
訂單以及後續將物品搬出倉庫，準備發貨
我們的資料需求：
通用的物品資訊，比如包裝數量、尺寸和顏色等可被儲存，但這些是我們可以識別並應用到任何物品上的離散資料。我們不太可能關注細節，例如筆記本處理器速度或者智慧型手機的電池壽命。
最小化出錯的可能是必要的。我們不能讓物品憑空消失或者移到已經有別的物品存放的位置。
簡單來說，我們在記錄物品從乙個物理區域到另乙個物理區域的轉移——或者從a位置移走，放到b位置。這是同乙個動作的兩次更新。
我們需要乙個具備強制資料完整性和事務支援的健壯儲存系統。只有 sql 資料庫滿足這些需求。
sql資料庫和nosql資料庫的區別
sql資料庫雖然教程多，支援也很強大，但是隨著網際網路應用的出現，sql資料庫遇到設計上的弊端，sql對錶的定義使得資料橫向擴充套件困難，而且sql資料庫的很多特性也沒有用武之地，例如及時訪問不是必要的，也沒有特別多的事物需求，這些特性都在消耗著sql資料庫的效能 因此nosql資料庫出現 sql資...
資料庫分類 SQL資料庫 NoSQL資料庫
一 資料庫產品 二.sql資料庫 sql 是所有關係型資料庫的公共語言 關係型資料庫，是建立在關係模型基礎上的資料庫，借助於集合代數等數學概念和方法來處理資料庫中的資料，我們平常使用的資料庫，像mysql，oracle，sql server等都是傳統的關係型資料庫。關係模型指的就是二維 模型，而乙個...
排名前十的SQL和NoSQL資料庫
原文連線 本排名根據db engines的排行榜得來，該排行榜從人氣上分析了市場上200個不同的資料庫，這裡一覽top 10。oracle mysql及microsoft sql server一直以絕對的優勢霸佔著排行榜的前三名，以獨特的優勢瓜分了市場上最多的使用者。1.oracle 11g 首次發...