Mongodb資料結構及與MySql對比

標籤：重要   idt   sel   medium   padding   架構設計   code   包含   複雜   

MySql一直是性價比最高的關係型資料庫典範

MongoDB帶來了關聯式資料庫以外的NoSql體驗。

  讓我們看一個簡單的例子，我們將如何為MySQL（或任何關聯式資料庫）和MongoDB中建立一個資料結構。

MySql設計

我們假設設計個表:

People 人物資訊表  包含ID 和名字欄位

passports 護照表 ,主要包含 對應的people表的外鍵ID ，所屬國家，和護照有效期間

mysql> select * from people;+----+------------+| id | name       |+----+------------+|  1 | Joker   ||  2 | John       ||  3 | Michael    ||  4 | Cinderella |+----+------------+mysql> select * from passports;+----+-----------+---------+-------------+| id | people_id | country | valid_until |+----+-----------+---------+-------------+|  4 |         1 | FR      | 2020-01-01  ||  5 |         2 | US      | 2020-01-01  ||  6 |         3 | RU      | 2020-01-01  |+----+-----------+---------+-------------+

 

於是你接下來可以操作如下準系統:

一共有多少人

SELECT count(*) FROM people

查詢出 Joker 的護照有效期間

SELECT valid_until from passports ps join people pl ON ps.people_id = pl.id WHERE name = ‘Joker‘

有多少人木有護照

SELECT name FROM people pl LEFT JOIN passports ps ON ps.people_id = pl.id WHERE ps.id IS NULL

 

 

MongoDB的設計

接下來是在MongoDB中進行設計

關係型資料庫中使用三範式，雖然規範的，但是效率不高，因為關聯度不高的情況下完全沒有必要使用三範式來設計。

  一種是“直筒式”的設計，和關係型資料庫的理解區別不大

{    "_id" : ObjectId("51f7be1cd6189a56c399d3bf"),    "name" : "Joker",    "country" : "FR",    "valid_until" : ISODate("2019-12-31T23:00:00Z")}{    "_id" : ObjectId("51f7be3fd6189a56c399d3c0"),    "name" : "John",    "country" : "US",    "valid_until" : ISODate("2019-12-31T23:00:00Z")}{    "_id" : ObjectId("51f7be4dd6189a56c399d3c1"),    "name" : "Michael",    "country" : "RU",    "valid_until" : ISODate("2019-12-31T23:00:00Z")}{ "_id" : ObjectId("51f7be5cd6189a56c399d3c2"), "name" : "Cinderella" }

 

MongoDB 無固定結構，每張表每段資料可以有不同的結構，這既是好處也是缺點，缺點在於你必須很瞭解MongoDB的表結構，這其實給維護人員帶來一定的不適應和麻煩。

 2、以下是MongoDb特徵的設計方法， 既：把people資訊和護照資訊柔和在一起

{    "_id" : ObjectId("51f7c0048ded44d5ebb83774"),    "name" : "Joker",    "passport" : {        "country" : "FR",        "valid_until" : ISODate("2019-12-31T23:00:00Z")    }}{    "_id" : ObjectId("51f7c70e8ded44d5ebb83775"),    "name" : "John",    "passport" : {        "country" : "US",        "valid_until" : ISODate("2019-12-31T23:00:00Z")    }}{    "_id" : ObjectId("51f7c71b8ded44d5ebb83776"),    "name" : "Michael",    "passport" : {        "country" : "RU",        "valid_until" : ISODate("2019-12-31T23:00:00Z")    }}{ "_id" : ObjectId("51f7c7258ded44d5ebb83777"), "name" : "Cinderella" }

 

3、同樣的，上述結構也可以欄位反過來設計，如果沒有“valid_until”欄位代表沒有護照

{    "_id" : ObjectId("51f7c7e58ded44d5ebb8377b"),    "country" : "FR",    "valid_until" : ISODate("2019-12-31T23:00:00Z"),    "person" : {        "name" : "Joker"    }}{    "_id" : ObjectId("51f7c7ec8ded44d5ebb8377c"),    "country" : "US",    "valid_until" : ISODate("2019-12-31T23:00:00Z"),    "person" : {        "name" : "John"    }}{    "_id" : ObjectId("51f7c7fa8ded44d5ebb8377d"),    "country" : "RU",    "valid_until" : ISODate("2019-12-31T23:00:00Z"),    "person" : {        "name" : "Michael"    }}{    "_id" : ObjectId("51f7c8058ded44d5ebb8377e"),    "person" : {        "name" : "Cinderella"    }}

 

Sum

MySQL和MongoDB的根本區別之一:

1、使用MongoDB， 架構設計變得無比重要，一旦中間有個環節設計的有問題，將會帶來災難性的維護和返工後果，後面更不用提最佳化。但是同樣的問題也逼著我們去做一個好的架構養成好的習慣。

2、哪種方式更好？當然，有沒有明確的答案。不同的環境使用不同的方式,就像上面這個例子完全使用MongoDB效率更高，譬如單表資料達到1000萬，mysql關聯查詢是很坑爹的。對於多商務邏輯複雜關聯設計，MongoDB不是不能勝任，關鍵我們不能保證我們的軟體需求像老外那樣不會一直變更或者推翻重寫，所以用mysql更易於維護

Mongodb資料結構及與MySql對比