SQL VS NoSQL如何选择数据库?

发表于:2016-11-01 10:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Linux公社    来源:51Testing软件测试网采编

  在前一篇文章中我们主要的讨论了SQL与NoSQL数据库之间的主要的差别。接下来,我们将会利用上一篇中的知识来确定在特定的场景中如何确定比较好的选择。
  首先我们先来总结一下:
  SQL数据库:
  · 使用表存储相关的数据
  · 在使用表之前需要先定义标的模式
  · 鼓励使用规范化来减少数据的冗余
  · 支持使用JION操作,使用一条SQL语句从多张表中取出相关的数据
  · 需要满足数据完整性约束规则
  · 使用事务来保证数据的一致性
  · 能够大规模的使用
  · 使用强大的SQL语言进行查询操作
  · 提供大量的支持,专业技能和辅助工具
  NoSQL数据库:
  · 使用类JOSN格式的文档来存储键值对信息
  · 存储数据不需要特定的模式
  · 使用非规范化的标准存储信息,以保证一个文档中包含一个条目的所有信息
  · 不需要使用JION操作
  · 允许数据不用通过验证就可以存储到任意的位置
  · 保证更新的单个文档,而不是多个文档
  · 提供卓越的性能和可扩展性
  · 使用JOSN数据对象进行查询
  · 是一种新型的技术
  SQL数据库适合那些需求确定和对数据完整性要去严格的项目。NoSQL数据库适用于那些对速度和可扩展性比较看重的那些不相关的,不确定和不断发展的需求。简单来说就是:
  · SQL是精确的。 它最适合于具有精确标准的定义明确的项目。典型的使用场景是在线商店和银行系统。
  · NoSQL是多变的。 它最适合于具有不确定需求的数据。典型的使用场景是社交网络,客户管理和网络分析系统。
  很少有项目能够很好的适用于一种数据库。如果你对数据的需求比较小或是非标准化的数据任何一种数据库都是可以的。你比我更了解你的项目,我不建议你将SQL上的数据移植到NoSQL上反之亦然,除非它能够提供非常可观的收益。当然选择权在于你自己。在项目的一开始就要考虑好使用它们的利弊,这样才不会导致选择错误。
  场景一:通讯记录
  我们来重新的定义操作并基于SQL实现通讯录系统。我们初始简单的定义 contact 表拥有如下几个字段;
  · id
  · title
  · firstname
  · lastname
  · gender
  · telephone
  · email
  · address1
  · address2
  · address3
  · city
  · region
  · zipcode
  · country
  问题一: 很少有人只拥有一个手机号。或许我们可以再添加三个字段:固定电话移动电话和工作电话,但是无论我们给一个联系人分配了多少个字段总会有人需要更多。我们需要创建一个单独的 telephone 表,这样就可以给一个联系人存多个号码了。这样也就规范化了我们的数据— 我们不需要一个没有电话的联系人:
  · contact_id
  · name  (说明字段:固定,工作,私人等.)
  · number
  问题二: 对于联系人邮箱我们也会遇到上述问题,因此我们也需要创建一个 email 的表:
  · contact_id
  · name  (说明字段:固定,工作,私人等.)
  · address
  问题三: 我们在填写联系人信息是我们并不希望填写他的地理位置,或者我们想记录他工作、生活、旅游的地方等。因此我们需要一个 address 表:
  · contact_id
  · name  (text such as home, office, etc.)
  · address1
  · address2
  · address3
  · city
  · region
  · zipcode
  · country
  我们原先设计的 contact 表就精简为:
  · id
  · title
  · firstname
  · lastname
  · gender
  好了,我们已经设计了一个规范化的数据库,可以用来存储任何一个联系人的电话号码,邮箱地址和住址了。但是......
  模式是固定不变的
  我们并没有考虑到联系人的生日,公司或者职位。不管我们添加多少个字段,我们会得到更多的需求:备注,周年纪念日,关系,社交账号,喜欢巧克力的种类等等。预测每一个需求对于我们来说是非常困难的,因此我们需要创建一张表其中存储的形式是键值对来应对不断增加的需求。
  数据是碎片化的
  对于开发人员和系统管理员来说不断地检查数据库是比较麻烦的。程序的逻辑会变得更复杂效率更慢,因为使用一条 select 语句来 JOIN 多个表来取出一个联系人的全部信息不太实际。 (当然这也是可以实现的,但是当一个联系人中国包含电话号码,邮件地址和住址信息时:如果一个人有3个电话号码,五个邮箱和两个住址,那么SQL查询会产生30个结果,也就是说说这样的效率会很慢。)
  最后,全文搜索是非常困难的。如果一个人要查询一个字符型:favorite,我们需要依次查询上述的四张表判断是否是一个联系人的姓名,电话,邮件或者地址依据这些把结果进行排序。如果你使用过 WordPress 的搜索,你就会发现是都么的烦人了!
  使用NoSQL来替代SQL
  我们的联系人关注的是人这个实体。然而关于人的信息是不可预测的并且在不同的阶段的需求也会不一样。如果我们使用NoSQL数据库会比较方便,NoSQL将一个人的信息存储为一个文档并放入 contacts 的集合中:
{
name: [
"Billy", "Bob", "Jones"
],
company: "Fake Goods Corp",
jobtitle: "Vice President of Data Management",
telephone: {
home: "0123456789",
mobile: "9876543210",
work: "2244668800"
},
email: {
personal: "bob@myhomeemail.net",
work: "bob@myworkemail.com"
},
address: {
home: {
line1: "10 Non-Existent Street",
city: "Nowhere",
country: "Australia"
}
},
birthdate: ISODate("1980-01-01T00:00:00.000Z"),
twitter: '@bobsfakeaccount',
note: "Don't trust this guy",
weight: "200lb",
photo: "52e86ad749e0b817d25c8892.jpg"
}
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号