学习数据库的心得体会
创新互联建站长期为上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为安平企业提供专业的做网站、网站建设，安平网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
在大二的下学期刚学了数据库这门课，对这门课的第一印象是书本蛮厚的，感觉学起来应该会很难很累。在学习这门课的过程中，在对数据库的了解过程中，慢慢对数据库有了感观。数据库这一词并不是很难想象，并不是像外人看来很神奇。作为计算机专业的学生，这样的专业术语或者专业知识是最基本的。
学习的时候没有想象中的那么难，只要上课能听懂就基本还可以。但是问题还是出在书本有点厚，有的时候上课的内容都要找很久才能找到，甚至有的时候老师讲的知识书本上是找不到的，是另外补充而且是相当重要的内容。有的时候开小差，没有听到老师讲的知识点，这就导致了以后的学习无法顺利进行，使得学习起来十分困难。所以在数据库这门课的学习中，上课一定要听牢，就像老师说的那样，这样的专业课如果想凭考试前几天突击是行不通的，必须是日积月累的知识才能取得好成绩。
通过对数据库的学习，我也明白了各行各业都离不开数据库，就算是一个小型的超市也离不开它。可见数据库这门课的广泛性，如果能够认真学好它将来必有成就。我就是抱着这种信念去学习数据库的。第一次接触数据库，第一次接触SQL语言，虽然陌生，但是可以让我从头开始学，就算没有基础的人也可以学得很好。刚开始练习SQL语言的时候，并不是很难，基本上都是按照老师的步骤来做，还很有成就感。后来学了单表查询和连接查询后，就慢慢发现越学越困难了，每个题目都要思考很久，并且每个题目基本上不止一个答案，所以必须找出最优的答案。后面的删除、插入、修改这些题目都变化蛮大的，书本上的例题根本无法满足我们，好在老师给我们提供了大量的课件，通过这些PPT，我们可以巩固课内的知识，还可以学习内容相关的知识，更好地完成老师布置的作业。
除了老师布置的一些基本作业外，还有一份大作业。就像我们小组的是杂货店的销售管理系统，在完成这一作业的过程中，我们可以通过网络实现一家杂货店。过程是很复杂的，杂货店需要员工，还有百来种商品，不仅需要大量的数据，还要完成需求说明，数据词典，还有E-R图等，虽然想象起来并不是很难，但是要转化成文字，转化成人们能够读懂的文字就显得十分困难。特别是一个完整的销售系统，对我们来说都是第一次接触，在做大作业的时候经常是前面改改，后面改改，因为一些数据不能很好地对应起来，经常会遗忘一些，所以出现了这样的情况。一个完整的数据库系统也就是在这样修修改改的状态下完成的，也给了我很大的反思。第一、一个数据库的完成一定要考虑各方面的因素，包括现实因素。第二、在完成这类作业时，修修改改是很正常的，不要因此而厌倦。第三、一个完整的数据库一定不能出现错误，否则会在现实生活中带来不必要的麻烦。
通过本学期数据库的学习及大作业的完成，很有去作项目的冲动，但深知自己的能力水平有限，还需要更多的学习。
自己删减一下。GOOD LUCK!
数据库课程设计心得 范文 1： 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本 方法 ，进一步提高我们综合运用所学知识的能力。
当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是Html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。
我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了痴迷的程度。然而Php是我刚接触不久的一种编程语言。不过觉得它的功能真的很强大，可以开发出很多大型的系统。但是在做备份和还原的时候，要考虑的东西还是很多的。当我遇到错误的时候，感到很受打击。值得欣慰的是，在同学的帮助和大量参考书的查阅下，我把自己的模块做好了。这就是我收获最大的地方。而且，我明白了遇到困难永不放弃的重要性，我知道了团队合作的重要性，我领悟了只有坚持不懈才会取得胜利。
知识的获得是无止境的，只要你想学，只要你行动，没有什么会难倒我们的。回首这一个多星期的课程设计，我很欣慰。因为我有了动力，有了勇气。谢谢老师对我们的不懈帮助，谢谢学校给了我们这一次实践的机会，也谢谢组员们的关怀。这些美好的回忆美好的东西将永远伴随着我。
数据库课程设计心得范文2：
一周的课程设计结束了，在这次的课程设计中不仅检验了我所学习的知识，也培养了我如何去把握一件事情，如何去做一件事情，又如何完成一件事情的方法和技巧。在设计过程中，和同学们相互探讨，相互学习，相互监督。我学会了运筹帷幄，学会了宽容，学会了理解，也学会了做人与处世，这次课程设计对我来说受益良多。
课程设计是我们专业课程知识综合应用的实践训练，着是我们迈向社会，从事职业工作前一个必不少的过程.“千里之行始于足下”，通过这次课程设计，我深深体会到这句千古 名言 的真正含义.我今天认真的进行课程设计，学会脚踏实地迈开这一步，就是为明天能稳健地在社会大潮中奔跑打下坚实的基础。我这次设计的科目是数据结。
数据结构，是一门研究非数值计算的程序设计问题中计算机的操作对象(数据元素)以及它们之间的关系和运算等的学科，而且确保经过这些运算后所得到的新结构仍然是原来的结构类型。作为一门独立的课程在国外是从20XX年才开始设立的。20XX年美国唐·欧·克努特教授开创了数据结构的最初体系，他所著的《计算机程序设计技巧》第一卷《基本算法》是第一本较系统地阐述数据的逻辑结构和存储结构及其操作的著作。“数据结构”在计算机科学中是一门综合性的专业基础课。数据结构是介于数学、计算机硬件和计算机软件三者之间的一门核心课程。数据结构这一门课的内容不仅是一般程序设计(特别是非数值性程序设计)的基础，而且是设计和实现编译程序、 操作系统 、数据库系统及其他系统程序的重要基础。
通过这次模具设计，我在多方面都有所提高。
一、编译工具VisualC++
很多程序在结构上是独立的，但是本此设计的程序功能不是零散的，它有一个连接是的程序是一个整体，怎样达到这种统一体呢?因为这个输出连接是贯穿始终的。说到这，就应该说以下我所应用的调试工具，也就是运行环境VisualC++，可以充分利用Windows的支持剪贴版和英文的特点。正是在实现循环链表的程序中充分利用这个特点，才能制作出全汉化的初始化画面。
二、巩固和温习了C语言
在界面设置中使用函数调用while。其中文本显示颜色和背景颜色都可以任意按照自己的喜好，任意改变，但改变的时候必须采用标准英文大写，同时在制作显示菜单的窗口，大小根据菜单条数设计。最后采用printf输出程序设计界面。
这次的程序软件基本上运行成功，可以简单的建立链式循环链表，并进行输出，及循环语句的运用和选择语句的控制。由于时间和知识上的限制，使得程序规模相对较小，即功能还不很全面，应用也不很普遍。原来C语言可是涉及很多知识，而不是枯燥无聊的简单的代码部分而已，利用C语言方面的知识，我们可以设计出更完善的软件。
三、积累了宝贵的 经验
我这次课程设计代码中主要使用了链表的循环和遍历这两中操作。循环链表(CircularLinkedList)是单链表的另一种形式，它是一个首尾相接的链表。其特点是将单链表最后一个结点的指针域由NULL改为指向头结点或线性表中的第一个结点，就得到了单链形式的循环链表，并称为循环单链表。类似地，还有多重链的循环链表。在循环单链表中，表中所有结点被链在一个环上，多重循环链表则是将表中的结点链在多个环上。为了使某些操作实现起来方便，在循环单链表中也可设置一个头结点。这样，空循环链表仅由一个自成循环的头结点表示。所谓遍历(Traversal)，是指沿着某条搜索路线，依次对树中每个结点均做一次且仅做一次访问。访问结点所做的操作依赖于具体的应用问题。
这次课程设计我选中的题目是个人资料的管理。编写了一个可以简易使用的个人资料管理系统，可以进行资料的输入和管理。虽然在我的程序中有一部分是从网上搜索得来的，但我已经竭力将所获得的信息变成自己的资源，动手上机操作，在了解和看懂的基础上有所改变和创新，但是在的程序软件中还有部分的不足，需要加以更新。仅管，我并没能很好的利用所学数据结构的知识，但我也尽了自己最大的努力用我所学来完成这次的课程设计。同时，通过这次课程设计，我认识到了自己动手实践的弱势，特别是在编程方面，知道了计算机的实践操作是很重要的，只有通过上机编程才能充分的了解自己的不足。
四、对以后的学习充满了信心和期待
通过这次的课程设计，更是让我深刻认识到自己在学习中的不足，同时也找到了克服这些不足的方法，这也是一笔很大的资源。在以后的时间中，我们应该利用更多的时间去上机实验，加强自学的能力，多编写程序，相信不久后我们的编程能力都会有很大的提高能设计出更多的更有创新的作品。
数据库课程设计心得范文3：
数据库课程设计大赛的尘嚣渐渐远去，怀着对这次大赛的些许不舍，怀着对当初课程设计开始时候的豪情万丈的决心的留恋，怀着通过这次课程设计积累的信心与斗志，我开始写这篇 文章 ，为自己的足迹留下哪怕是微不足道但是对自己弥足珍贵的痕迹并期望与大家共勉。
首先，让我的记忆追溯到大二暑假，在老大的指引下(老大劝我学asp.net)，我接触到microsoft 公司的.net产品。那个时候我已经学过vc和asp，因为windows程序设计实验的课的关系，接触过vb，但是没有专门去学他，因为习惯了c++里面的class，int，觉得vb的sub，var 看着就不是很顺心。我是一个好奇心很强的人，突然看到了一个号称“.net是用于创建下一代应用程序的理想而又现实的开发工具”，而且主推c#语言，由于对c语言的一贯好感，我几乎是立刻对他产生了兴趣。我就开始了对c#的学习，任何语言都不是孤立存在的，所以数据交互是很重要的，暑假的时候我把我们这学期的课本数据库系统概论看了一遍。我记得以前用c语言编程的时候，数据是在内存中申请空间，譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来的时候啦，于是我又装上了sql server2000，以前学asp的时候用的是access，那个时候只是照着人家做，理论是什么也不是很清楚。
通过一个暑假的学习，基本搞清楚了理论方面的东西，具体怎么用也不是很清楚。但是这为这学期的课程设计打下了铺垫。
来到学校后，随着这学期的数据库课程大赛开始了，我有一个看法就是我自己应该具备的能力不是我会多少，而是我应该具备快速学会东西的能力。遇到什么就学什么。我们有时候很容易被一些专业名词说吓着，包括什么建模，软件工程，数据分析，数据挖掘等等。我身边就有很多同学被这些纸老虎所唬住，而没有勇气去接触他们，总是说这个太难了之类的退堂鼓的话，他们低估了自己的潜力同时也压抑住了他们自己的好奇心。其实都是纸老虎，又不是什么国家科研难题，只是去用一些工具，发明工具是很难，但是用一个工具就容易多了，just do it!我记得我做这个数据库之前，我们老师说要做好前期分析，我就在网上搜索用什么分析工具好。最后我选择了roseuml建模工具。在此之前，我脑袋里面没有软件建模的思想，什么uml建模对我而言就是一张空白的纸。但是真正接触后并没有想象的那么难，有什么不懂的上网去搜索，这是一个信息横流的世界，有google，baidu就没有不能解决的知识难题。以及后来的数据库分析的时候用到的powerdesigner也是一样。
开发的时候我想过用什么架构，c/s模式?模式有很多，怎么选择?我就上网搜索现在最流行的架构是什么。结果搜到了mvc架构，就是你啦。我决定用这个架构，不会，没关系，咱学。just do it!前期工作准备好后，那么我就得把我暑假学的.net加以实践。这个时候我更加深入的了解了利用ado.net操纵数据库的知识。并且对数据库里面的存储过程有了比较深入的了解。经过大概2个多星期的奋斗，我完成了我的数据库课程设计--基于.net数据集的图书馆管理系统。并最后非常荣幸的获得了大赛的一等奖以及以及新技术应用奖。
与其临渊羡鱼，不如退而结网。这次数据库课程设计给我的最大的印象就是如果自己有了兴趣，就动手去做，困难在你的勇气和毅力下是抬不了头的。从做这个数据库开始无论遇到什么困难，我都没有一丝的放弃的念头。出于对知识的渴望，出于对新技术的好奇，出于对一切未知的求知。我完成了这次数据库课程设计，不过这只是我学习路上的驿站，未来十年.net的核心技术就是xml[至少微软是这么宣传的]，我会继续学习它，包括jave公司的j2ee我也很想试试，语言本来就是相通的，just do it!语言并不重要毕竟它仅仅是工具，用好一个工具并不是一件值得为外人道的事情，主要是了解学习思想。古语说的好：学无止境啊!
我很庆幸我参加了这次数据库大赛，让我确实打开了眼界。
传统观念中 NoSQL数据库非常适合某些数据类型，如：非关系数据源。同时，NoSQL被吹捧为最适合Web应用程序的优秀平台。然而他适合大多数数据，特别是web应用程序的数据是相关型。那么，这是否可以给你一个坚持使用RDMS的理由呢？也不一定，即使很困难，我们还是要做出选择。
评估NoSQL是一个很茅盾的理论，一些人认为，应该将所有文档数据存储在一个文档中，做链接代码就是亵渎神明。另外一部分人认为，存储应用文档，加入代码，才是合理选择。与此同时，不同的数据库，需要在文档中限制嵌套数据数量。有的人会鼓励文档引用。这是NoSQL数据模型的基本部分，也没有一个明确的共识。
曾经有一篇很热的帖子"Why you should never use XYZ"，我想，读到这里，一定会有人搜索这篇文章。当然，这种文章各式各样，太过于笼统的标题也没什么帮助。毫无疑问，会有人会搜索这个文章，然后再找
到这个文章，进一步深入，找到该文章的方法远比成功（理解问题）的故事多。很难知道谁提供了一个有效的技术问题，谁又误读了这个问题（或者缺少证据证明其观点）。
有大量选择，RDBMS的世界，选择就很容易。你有4或5个目标，大家工作方式差不多，来选择环境、预算支持的平台。对于成熟的产品，风险比较小。 NoSQL的世界，有很多数据库引擎功能选择。每一个有自己的独特优势，也有致命弱点。所以选择很难， NoSQL项目生命周期短，尝试新项目或者流行项目也会有风险。上次，我的的项目是在 CouchDB上，而现在似乎停摆了。
做出这个痛苦决定的原因是，这可能是一个案例：你需要做一大堆工作，才能知道，你做出的选择对与错。你可以实体化你的数据模型，了解他与系统的工作情况，但是，这只有你正真撞到南墙，才可以找到裂缝（答案）。以我为例，我建的应用程序是关系数据库，移动文件存储的主要因素是，需要一个无模式设计来达到我的目标。使用NoSQL 数据库存储关系型数据库并不是我们所常说的，虽然，这种事常常发生。
现在我在用 Couchbase 和 MongoDB，Mongo对我没多大吸引力，不过鉴于他非常流行，对于引起来说，很有好处。当然，很多都可以以同样的方式流行。PHP很流行，因为他的易用性，而不是因为他很好。
NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。
目录
- 数据库分类维度：关系型/非关系型、交易型/分析型
- NoSQL数据库的进一步分类
- OLTP市场规模：关系型数据库仍占营收大头
- 数据库市场份额：云服务和新兴厂商主导NoSQL
- 开源数据库 vs. 商业数据库
- 数据库三大阵营：传统厂商和云服务提供商
最近由于时间原因我写东西少了，在公众号上也转载过几篇搞数据库朋友的大作。按说我算是外行，没资格在这个领域品头论足，而当我看到下面这份报告时立即产生了学习的兴趣，同时也想就能看懂的部分写点心得体会分享给大家。
可能本文比较适合普及性阅读，让数据库领域资深的朋友见笑了：）
数据库分类维度：关系型/非关系型、交易型/分析型
首先是分类维度，上图中的纵轴分类为Relational Database（关系型数据库，RDBMS）和Nonrelational Database （非关系型数据库，NoSQL），横轴的分类为Operational（交易型，即OLTP）和Analytical（分析型，即OLAP）。
按照习惯我们先看关系型数据库，左上角的交易型类别中包括大家熟悉的商业数据库Oracle、MS SQL Server、DB2、Infomix，也包括开源领域流行的MySQL（MariaDB是它的一个分支）、PostgreSQL，还有云上面比较常见的SQL Azure和Amazon Aurora等。
比较有意思的是，SAP HANA正好位于交易型和分析型的中间分界处，不要忘了SAP还收购了Sybase，尽管后者今天不够风光了，而早年微软的SQL Server都是来源于Sybase。Sybase的ASE数据库和分析型Sybase IQ还是存在的。
右上角的分析型产品中包括几款知名的列式数据仓库Pivotal Greenplum、Teradata和IBM Netezza（已宣布停止支持），来自互联网巨头的Google Big Query和Amazon RedShift。至于Oracle Exadata一体机，它上面运行的也是Oracle数据库，其最初设计用途是OLAP，而在后来发展中也可以良好兼顾OLTP，算是一个跨界产品吧。
再来看非关系型数据库，左下角的交易型产品中，有几个我看着熟悉的MongoDB、Redis、Amazon DynamoDB和DocumentDB等；右下角的分析型产品包括著名的Hadoop分支Cloudera、Hortonworks（这2家已并购），Bigtable（来自Google，Hadoop中的HBase是它的开源实现）、Elasticsearch等。
显然非关系型数据库的分类要更加复杂，产品在应用中的差异化也比传统关系型数据库更大。Willian Blair很负责任地对它们给出了进一步的分类。
NoSQL数据库的进一步分类
上面这个图表应该说很清晰了。非关系型数据库可以分为Document-based Store（基于文档的存储）、Key-Value Store（键值存储）、Graph-based（图数据库）、Time Series（时序数据库），以及Wide Cloumn-based Store（宽列式存储）。
我们再来看下每个细分类别中的产品：
文档存储 ：MongoDB、Amazon DocumentDB、Azure Cosmos DB等
Key-Value存储 ：Redis Labs、Oracle Berkeley DB、Amazon DynamoDB、Aerospike等
图数据库 ：Neo4j等
时序数据库 ：InfluxDB等
WideCloumn ：DataStax、Cassandra、Apache HBase和Bigtable等
多模型数据库 ：支持上面不只一种类别特性的NoSQL，比如MongoDB、Redis Labs、Amazon DynamoDB和Azure Cosmos DB等。
OLTP市场规模：关系型数据库仍占营收大头
上面这个基于IDC数据的交易型数据库市场份额共有3个分类，其中深蓝色部分的关系型数据库（RDBMS，在这里不统计数据挖掘/分析型数据库）占据80%以上的市场。
Dynamic Database（DDMS，动态数据库管理系统，同样不统计Hadoop）就是我们前面聊的非关系型数据库。这部分市场显得小（但发展势头看好），我觉得与互联网等大公司多采用开源+自研，而不买商业产品有关。
而遵循IDC的统计分类，在上图灰色部分的“非关系型数据库市场”其实另有定义，参见下面这段文字：
数据库市场份额：云服务和新兴厂商主导NoSQL
请注意，这里的关系型数据库统计又包含了分析型产品。Oracle营收份额42%仍居第一，随后排名依次为微软、IBM、SAP和Teradata。
代表非关系型数据库的DDMS分类中（这里同样加入Hadoop等），云服务和新兴厂商成为了主导，微软应该是因为云SQL Server的基础而小幅领先于AWS，这2家一共占据超过50%的市场，接下来的排名是Google、Cloudera和Hortonworks（二者加起来13%）。
上面是IDC传统分类中的“非关系型数据库”，在这里IBM和CA等应该主要是针对大型机的产品，InterSystems有一款在国内医疗HIS系统中应用的Caché数据库（以前也是运行在Power小机上比较多）。我就知道这些，余下的就不瞎写了。
开源数据库 vs. 商业数据库
按照流行度来看，开源数据库从2013年到现在一直呈现增长，已经快要追上商业数据库了。
商业产品在关系型数据库的占比仍然高达60.5%，而上表中从这列往左的分类都是开源占优：
Wide Cloumn：开源占比81.8%；
时序数据库：开源占比80.7%；
文档存储：开源占比80.0%；
Key-Value存储：开源占比72.2%；
图数据库：开源占比68.4%；
搜索引擎：开源占比65.3%
按照开源License的授权模式，上面这个三角形越往下管的越宽松。比如MySQL属于GPL，在互联网行业用户较多；而PostgreSQL属于BSD授权，国内有不少数据库公司的产品就是基于Postgre哦。
数据库三大阵营：传统厂商和云服务提供商
前面在讨论市场份额时，我提到过交易型数据库的4个巨头仍然是Oracle、微软、IBM和SAP，在这里William Blair将他们归为第一阵营。
随着云平台的不断兴起，AWS、Azure和GCP（Google Cloud Platform）组成了另一个阵营，在国外分析师的眼里还没有BAT，就像有的朋友所说，国内互联网巨头更多是自身业务导向的，在本土发展公有云还有些优势，短时间内将技术输出到国外的难度应该还比较大。（当然我并不认为国内缺优秀的DBA和研发人才）
第三个阵容就是规模小一些，但比较专注的数据库玩家。
接下来我再带大家简单过一下这前两个阵容，看看具体的数据库产品都有哪些。
甲骨文的产品，我相对熟悉一些的有Oracle Database、MySQL以及Exadata一体机。
IBM DB2也是一个庞大的家族，除了传统针对小型机、x86（好像用的人不多）、z/OS大型机和for i的版本之外，如今也有了针对云和数据挖掘的产品。记得抱枕大师对Informix的技术比较推崇，可惜这个产品发展似乎不太理想。
微软除了看家的SQL Server之外，在Azure云上还能提供MySQL、PostgreSQL和MariaDB开源数据库。应该说他们是传统软件License+PaaS服务两条腿走路的。
如今人们一提起SAP的数据库就想起HANA，之前从Sybase收购来的ASE（Adaptive Server Enterprise）和IQ似乎没有之前发展好了。
在云服务提供商数据库的3巨头中，微软有SQL Server的先天优势，甚至把它移植到了Linux拥抱开源平台。关系型数据库的创新方面值得一提的是Amazon Aurora和Google Spanner（也有非关系型特性），至于它们具体好在哪里我就不装内行了：）
非关系型数据库则是Amazon全面开花，这与其云计算业务发展早并且占据优势有关。Google当年的三篇经典论文对业界影响深远，Yahoo基于此开源的Hadoop有一段时间几乎是大数据的代名词。HBase和Hive如今已不再是人们讨论的热点，而Bigtable和BigQuery似乎仍然以服务Google自身业务为主，毕竟GCP的规模比AWS要小多了。
最后这张DB-Engines的排行榜，相信许多朋友都不陌生，今年3月已经不是最新的数据，在这里列出只是给大家一个参考。该排行榜几乎在每次更新时，都会有国内数据库专家撰写点评。
以上是我周末的学习笔记，班门弄斧，希望对大家有帮助。
参考资料《Database Software Market:The Long-Awaited Shake-up》
扩展阅读：《 数据库存储：互相最想知道的事 》
尊重知识，转载时请保留全文。感谢您的阅读和支持！
