MySql一直是性价比最高的关系型数据库典范
MongoDB带来了关系数据库以外的NoSql体验。
让我们看一个简单的例子，我们将如何为MySQL（或任何关系数据库）和MongoDB中创建一个数据结构。
MySql设计
我们假设设计个表:
People 人物信息表 包含ID 和名字字段
passports 护照表 ,主要包含 对应的people表的外键ID ，所属国家，和护照有效期
|
|
mysql> select * from people; +----+------------+ | id | name | +----+------------+ | 1 | Stephane | | 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 |
查询出 stephane 的护照有效期
|
SELECT valid_until from passports ps join people pl ON ps.people_id = pl.id WHERE name = 'Stephane' |
有多少人木有护照
|
SELECT name FROM people pl LEFT JOIN passports ps ON ps.people_id = pl.id WHERE ps.id IS NULL |
接下来是在MongoDB中进行设计
上述关系型数据库中使用三范式，固然是规范的，但是效率不高，因为关联度不高的情况下完全没有必要使用三范式来设计。
一种是“直筒式”的设计，和关系型数据库的理解区别不大
|
|
{ "_id" : ObjectId("51f7be1cd6189a56c399d3bf"), "name" : "Stephane", "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" : "Stephane", "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" : "Stephane" } } { "_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" } } |
我们看到MySQL和MongoDB的根本区别之一，
1、使用MongoDB， 架构设计变得无比重要，一旦中间有个环节设计的有问题，将会带来灾难性的维护和返工后果，后面更不用提优化。但是同样的问题也逼着我们去做一个好的架构养成好的习惯。
2、哪种方式更好？当然，有没有明确的答案。不同的环境使用不同的方式,就像上面这个例子完全使用MongoDB效率更高，譬如单表数据达到1000万，mysql关联查询是很坑爹的。对于多业务逻辑复杂关联设计，MongoDB不是不能胜任，关键我们不能保证我们的软件需求像老外那样不会一直变更或者推翻重写，所以用mysql更易于维护
京公网安备 11010802040832号 | 京ICP备19059560号-6 