如何选择简单易用的数据库

1.数据量太大，比如上亿，就用oracle，优点上亿数据对Oracle来说轻飘飘的，也不用太多优化配置，缺点安装比较麻烦，上手比较慢。

2.数据量较大，比如千万级，用postgresql，它号称对标Oracle，处理千万级数据还是可以的，也是易学易用。

3.数据量一般，比如百万级，用mysql，这个级别的数据量mysql处理还是比较快的。

4.数据量较小，比如十万以下，sqlite、access都可以。

上面是基于单表操作的数据量，你看着选。

简单易用的数据库哪个比较好？这个要具体看你的用途，如果数据量比较少（10万左右），追求简约简单，免费开源的sqlite就行，如果数据量比较多，考虑到高并发、分布式，可以使用专业的mysql、postgresql，下面我分别简单介绍一下，感兴趣的朋友可以尝试一下：

小巧灵活sqlite

这是基于c语言开发的一个轻量级关系型数据库，短小精悍、免费开源，个人使用无需繁琐的配置，只需一个简单的运行库便可直接使用，针对各种编程语言都提供了丰富的API接口， java、 python、c#等都可轻松操作，如果你存储数据量不多，只是本地简单的操作（读多写少），可以使用一下这个数据库，占用内存非常少，轻便灵活，当然，在高并发、数据量大的情况下就不合适了：

专业强大mysql

这是目前应该广泛使用的一个关系型数据库，免费开源跨平台，在信息系统开发方面一直占据着主力位置，如果你从事于web开发或者网站后台建设，那么这个数据库一定非常熟悉，支持高并发、分布式，存储数据量相对于sqlite来说，更多也更安全，索引、触发器、存储过程等功能非常不错，支持数据导入导出、恢复备份，只要你熟悉一下基本使用过程，很快就能掌握和运用：

免费开源postgresql

这是加州大学计算机系开发的一个对象-关系型数据库（自由软件），免费、开源、跨平台，支持流计算、全文检索、图式搜索、并行计算、存储过程、空间数据、K-V类型，相比较mysql来说，在复杂查询、高并发下更稳定、性能更优越，可扩展性、可维护性非常不错，但也有劣势，例如新旧版本不分离存储，没有Coverage index scan等，总体使用效果来说还不错：

当然，除了以上3个数据库，还有许多其他数据库，像mssql、oracle等也都非常不错，对于存储和处理数据来说绰绰有余，只要你熟悉一下基本使用过程，很快就能入门的，网上也有相关教程和资料，介绍的非常详细，感兴趣的话，可以搜一下，希望以上分享的内容能对你有所帮助吧，也欢迎大家评论、留言进行补充。

最符合初学者理解和入门的是Access，因为它和Excel本来就是一个套件，相互转化容易，复制粘贴即可，非常好理解库、表、字段、键的概念。

如果数据量不大，强烈推荐试试Filemaker，脚本化编程，自由定制输入界面、工作流程，非常便捷高效。

最近杀出来的airtable，更是简单高效，界面美观，操作与电子表格相当，发展势头也非常迅猛。

二者侧重点有所不同，用户可根据需要选择

作为一个软件开发人员，长期需要和数据库打交道，个人更加青睐于MySQL。虽然可能基于你的Excel原因，有些人会建议你使用Access数据库，但是基于我个人的 意见，我并不建议你那样做。采用MySql的具体理由如下：

1.MySQL具有普遍性，在国内的环境中，绝大多数的互联网企业采用的是MySQL。有了广大的用户基础后，针对于各种问题网上也能更好地找到解决方案。

2.MySQL相对于Oracle而言，更加轻量化，针对于从Excel量级的数据，没必要使用Oracle。同时MySQL是完全免费的，不用担心版权及费用问题，无论对个人还是对预算有限的企业而言都是很好的选择。

3.MySQL高度兼容标准SQL，这对于以后迁移到其他数据库而言，也能很大程度地降低学习成本。

希望我的回答能够对你有所帮助！！！[耶][耶][耶]

Excel办公确实便利，可以做一些简单的数据分析，但涉及大量复杂的数据运算，就会遇到和题主一样的问题，运算速度慢，如果主机性能不是很好，还有可能面临电脑死机，数据丢失等问题。

遇到这种情况，我们该如何解决呢？数据库的重要性显而易见！

现在， 我将用3分钟的时间，与您探讨该选择何种数据库，以及选择它的理由，是否有更优的解决方案呢？

MySQL数据库，90%的企业都会选择它

数据库选得好，企业的数据安全，资产安全，也就得到了保障。那么该如何选择数据库呢？这个跟你的业务量和业务服务行业，密不可分。

如果你只是上班打卡，用SQL server就可以了；

如果你要储存会话信息，用户配置信息，购物车数据，建议使用NoSQL数据库；

不过90%的企业或个人，首选数据库都是MySQL数据库。

为什么这么说？

因为，它集 低成本、高可用、可靠性强、易用性强、体积小、速度快开放源码 等特性于一身，所以在金融、财务、网站、 数据处理 等应用领域，它占据着独一无二的优势。

这也是几乎所有企业都选择它，来存储数据的原因。

加之MySQL数据库，支持多种存储引擎，支持大型数据库，可以处理成千上万条记录，还提供用于管理、检查、优化数据库操作的工具。

因而，MySQL尤其受个人，以及中小企业的推崇。

虽然MySQL数据库简单易用，但我还是不会部署该怎么办？

别担心，现在市面上已经出现了，一种自带数据库的新型办公软件。

比如说，云表企业应用平台，一款兼容excel功能，但功能更为强大的办公软件，它就内嵌了MySQL数据库。 （文末有免费获取方式）

云表内嵌的MySQL数据库，有何优点？

1. 性能更加优化，更加兼容系统。因为云表的研发人员，时刻更新维护MySQL数据库。

2. 省去自己手动部署的麻烦。但如果你熟悉部署数据库，想把数据库改成Oracle或SQL server等数据库，也可以设置。（不过，我建议IT小白还是 “拿来即用” 就好）

3. 快速实时计算。数据分析实时交互，完全满足管理决策中的临时性分析，多变的业务需求，以及频繁的结果刷新。

4. 通过自带的内存计算引擎，无需事先建立CUBE，IT部门将告别报表延时报表分析，亿级数据秒级响应。

内嵌的MySQL数据库是否可靠

云表不仅是一款办公软件，同时还是一款开发工具。

通过它，你将解决以下问题：

复杂的数据运算，精确到行列的权限管控，以及工作流，海量用户同时在线办公，数据透视，制作像销售单，洽谈合同等表单报表，一份制作，即可重复录用......

你还可以通过它，与电子称、地磅等进行对接，与用友金蝶等三方系统集成，生成条形码，扫码出入库，生成移动端APP...... 基本上业务所需的功能，你都可以放心交给它做。

它最大的亮点就是，你可以 用使用excel的手法，用它来开发业务应用。

而且，可视化的 拖拉拽 之后，开发出来的ERP、WMS、OA、进销存等业务应用，还秉承了MySQL数据库增删改查的功能特性。

没错，用云表开发出来的业务应用，是允许二次开发的，而且功能可以随时增删改查，轻松满足大集团精细化的数据控制需求。

不过，大家最关心的应该是数据安全问题吧。

数据存放在云表内嵌的MySQL数据库，是安全不丢失的，它提供了多种数据存储的方式，本地部署，云端部署，混合部署，任君挑选！

正因如此，像 恒逸石化、许继电气、航天科工委、中铁、中冶、云南小松 等大型集团，才鼓励内部员工去学习云表。

篇幅所限，只说到这里，说太多你也不会看。

免费 的软获取方式在下方：

数据库的用处可大着呢，不仅可以实现数据共享，减少数据冗余度，还能实现对数据的集中控制，保持数据的一致性和可维护性。选取简单易用的数据库，你有什么好的建议呢，留言让我们看到噢！

题主强调了简单易用。所以推荐最简单三个。

1.Access。

2.Excel。

3.飞书文档、腾讯文档、石墨文档等的表格。

如果要做分析，数据量才比较大，建议Access，还是专业的更好一些。网上教程也很多，比较容易学。而且建议用早一点的版本，比如2003或者2007，Access这些年微软一直想从office里去掉，奈何用的人还是很多，所以不敢去掉，但是采取了一种比较恶心的方法让用户放弃，就是每发布一个新版本，就去掉一些好用的功能，所以说Access是越早的功能越强。

还一个推荐就是Sql Server Express版本，是SQL Server的免费版本，不要钱，基本功能都有，要比sqllite等强大的多

这要结合你个人实际情况来定，有计算机基础，懂一点数据库的话那么市场上的那些软件都可以用，常用有oracle，sqlserver，mysql等，要上手快还是sqlserver比较快，界面操作也比较直观；如果一点基础都没有，但是又要分析数据的话可以用微软自带的一个access，这个上手比较快。决定用哪一种之后还是要买点教材看，简单的sql查询要会，熟练之后也能提高工作效率。

个人使用数据库的话，只存数据不做分析，SQLite就足够了。

如何选择数据库

柳树

公众号：柳树的絮叨叨

关注他

30 人赞同了该文章

我们正在做一个电子书小程序。

1.0 层次模型数据库

用户购买，生成订单，订单详情里有用户购买的电子书：

一层一层铺开，一对多，这是「层次模型数据库」（Hierarchical Database）。

2.0 网状模型数据库

一笔订单可以购买多本电子书，一本电子书也可以被多笔订单购买：

这就形成了「多对多」的「网状模型数据库」（Network Database）。

上面讲的两种数据库，也许你听都没听过。

我们用的，是「关系模型」，而非上面的「层次模型」或者「网状模型」。

为什么？

你会说，这样不方便遍历所有订单。

并不会，再加一个根节点就好：

你会说，这样查找效率很低。

也不会，因为可以优化下数据结构，比如换成 B+ 树。

为什么我们从一开始就在用「关系模型数据库」？

3.0 关系模型数据库

无论是层次模型还是网状模型，程序员看到的，都是实实在在的物理存储结构。

查询时，你要照着里面的数据结构，用对应的算法来查；

插入时，你也要照着数据结构，用对应算法来插入，否则你就破坏了数据的组织结构，数据也就坏掉了。

因为我们都没用过前面两种数据库，所以觉得「关系模型数据库」（以下简称 RDB）的一切都理所当然，但其实，它做出了一个革命性的变革：

用逻辑结构（logical representation of data）代替物理结构（physical representation of data）

所谓「逻辑结构」，也就是我们经常看到的「表格」，User 是一张表格，Order 是一张表格，Book 又是一张表格，它们之间的关系，用 id 来关联，这些 id，可能是 number 类型，也可能是 string 类型

但你看到的，不一定就是实际的，你看到的只是让你方便理解的「逻辑结构」，真实数据自然不是这样按表格来存储，表格无异于一个数组，数组查询是很慢的。

真实的「物理结构」，也许还是像「层次模型」和「网状模型」一样，是复杂的数据结构。

但到底是怎样的数据结构，你都无需关心，你只需把它想象成一张「表」去操作，就连可视化工具，都会帮你把数据可视化成表，来方便你理解。

这个观念的提出，来自于 1970 年 Codd 的一篇论文，A Relational Model of Data for Large Shared Data Banks：

Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). 

Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed. 

—— Codd

Codd 的这种思想，其实就是经济学里提到的：分工产生效能。

程序员们不需要直接和物理结构打交道，只负责告诉数据库，他想做什么，至于数据是如何存储、如何索引，都交给数据库，最终他们看到的就是一张张特别直观、特别好理解的 excel 表格。

而数据库则把维护物理结构的复杂逻辑，交给了自己， 对程序员屏蔽了复杂的实现细节。

开发时写的代码少了，耦合性降低了，数据也不容易损坏，也就提高了生产效率（productive）。

一切能用同样的耗能，带来更多效能的技术，都会被广泛使用。

NoSQL

那后来为什么又有了 NoSQL 呢？

在 RDB 被发明的时代，软件多用于大型企业，比如银行、金融等等，人们对数据的要求非常纯粹：准确、可靠、安全，让数据按照期望，正确的写入，不要给老子算错钱就好，于是有了具有 ACID 特性的事务：原子性、一致性、隔离性和持久性。

那时候用网络的人很少，通过终端来访问客户端的人，更少，自然的，数据库的数据量和访问量都跟现在没法比，一台机器，足矣，最多再来个一主多从：

后来，你知道的，每个人手里都有个手机，每分每秒，都有成千上万的数据，写入你的数据库、从你的数据库被查出，于是有了「分布式」，有了 BASE 和 CAP。这时候，RDB 就会发现，自己之前的那一套 ACID，竟然有点作茧自缚了：

为了保证事务的隔离性，要进行加锁，在分布式的环境下，就要对多台机器的数据进行加锁；

为了保证事务的原子性，在机器 A 的操作和在机器 B 的操作，要么一起成功，要么一起失败；

…...

这些都要去不同节点的机器进行通讯和协调，实现起来非常复杂，而且要付出更多的网络 IO，影响性能。

ACID 在分布式系统上实现起来就会变得难以实现，即使实现了，也要付出很大的性能成本，于是才有了后来的各种「分布式一致性协议」，Paxos、Raft、2PC …… 而 Mysql 也提供了各种方案来实现分布式，当然，这些方案自然是很复杂的，比如 「NDB Cluster」 ：

而 NoSQL 则没有这么多承诺，它的一致性，一般都是最终一致性，当然你可以选择强一致，那自然就要付出点性能作为代价，当然你还可以弱一致，这样会更不安全，但是更快，一切取决于你对数据的要求。

除此之外，RDB 的「数据库范式」（Database Schema），也成了限制扩展性的瓶颈。为了避免数据冗余导致的各种问题（占用空间、删除异常、更新异常等等），我们在设计关系模型时，通常都是按照最小单位来设计的。

什么叫最小单位，比如用户有地址和爱好，那么在正确设计的关系模型（比如 3NF）里，这就是三张表：

如果这三张表被分散在不同的机器，那进行关联查询时，就需要多次跨机器的通讯；

而对于 NoSQL，这三类信息，都可以利用 Json 格式的数据，将它们存放在一起：

完整的存储进去，完整的取出来，不需要额外的操作。

NoSQL 比 RDB 有更强的扩展性，可以充分利用分布式系统来提升读写性能和可靠性。

这不是谁设计好坏的问题，而是跟他们要解决的问题有关：RDB 诞生于互联网萌芽的时代，那时数据的准确、可靠是最重要的，而 NoSQL 诞生于互联网快速发展普及的时代，大数据、分布式、扩展性成了数据库的另一个重要特性。

总结一下：

RDB 首先得是准确、可靠，然后才向更高的「可拓展性」发展；

而 NoSQL 生而分布式，可拓展性强，然后才向更高的「准确性」发展。

NoSQL ，not only SQL，其实就是对那种打破了 RDB 严格事务和关系模型约束的那些数据库的泛指，而随着要解决的问题的不同，又诞生了各种各样的 NoSQL。

首先是「列式数据库」（Column-oriented DBMS），数据量上去了，我们想分析网站用户的年龄分布，简单说，就是你需要对同一个特征进行大数据量的分析统计，于是把原来 RDB 的「按行存储」的范式打破，变成了「按列存储」，比如 HBase；

然后你发现有些数据变动不是很大，但是经常需要被查询， 查询时还要关联很多张表，于是你把这些来自不同表的数据，揉成一个大对象，按 key-value 的格式存起来，比如 Redis；

再后来你需要对博客内容进行相关性搜索，传统 RDB 不支持相关性搜索，最重要的，还是扩展性差，增加机器的带来边际效益有限，于是有了「全文搜索引擎」，比如 Elasticsearch；

除此之外，还有「文档数据库」、「图形数据库」……

没有一种数据库是银弹。

总结

这篇文章的题目是「如何选择数据库」，这是困扰很多人的问题，那么多数据库，到底要选什么好？

可是当你问出这样一个问题时，其实你是在问一种「手段」。我现在要做这样一个需求，用什么数据库可以帮我实现它？

但其实你需要的不只是一种「手段」，因为如果对方甩给你一个冷冰冰的名字，Mysql、Elasticsearch、MongoDB，你肯定会问，凭什么？

你需要的，是一种「解决方案」。如果你需要数据十分严格准确，分毫不差，那我会推荐你采用「事务」和「关系模型」来处理数据；如果你需要数据能够被大量读取和写入，那我会推荐你扩展性强的「分布式」；如果你的数据经常是整个读取、整个更新的，那「关系模型」就没有「文档模型」适合你。

「事务」、「关系模型」、「分布式」、「文档模型」等等，这些就是「解决方案」，知道用什么「解决方案」，用哪个数据库，自然水到渠成。

正如一位大牛说的：

设计实践中，要基于需求、业务驱动架构。无论选用 RDB/NoSQL，一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计。

用户不会因为你用了 Mysql 或者 MongoDB 而使用你的软件，毕竟绝大多数用户都不知道 Mysql 和 MongoDB 是什么玩意。

如何选择数据库

一般来讲，数据分析的查询不会直接从生产环境的数据库来读取数据，一方面是影响线上性能，另一方面是OLTP的表结构设计更多的是面向插入，而不是读取。如何来选择合适的数据库做数据分析呢？本文给出了四方面的考量，抛砖引玉。

1. 客户要分析什么样的数据

2. 客户分析的数据量是多少

3. 客户工程师团队技术背景，运维能力

4. 预期的数据分析的响应时间

客户要分析什么样的数据

上文已简单介绍了关系型数据库和非关系型数据库的区别，这里就不再赘述。下图是一个简单的分类。

客户分析的数据量是多少

用户需要分析的数据量越大，就越应该考虑非关系型数据库。

上图给出了选择合适数据库的思路。不同的数据库处理数据的能力不同。如果你打算处理1T以下的数据，那么可以使用Postgres或者MySQL，但如果数据量增大到5T以上，需要在扩展性方面下些功夫。当然，各个数据库厂商也在不断的优化性能，像微策略这样的BI平台也在紧跟各个厂商的步伐，对各个数据库的特性进行深入的研究，把数据库新特性运用到BI产品中，给客户深入分析各个数据库的优势劣势， 确保为客户提供最大的投入产出比。

客户工程师团队技术背景，运维能力

客户需要了解自己技术团队的人员结构、技术偏好。如果有强大的技术团队，关系型和非关系型数据库都可选择。一般来讲，非关系型数据库需要更多管理维护的时间。如果没有足够的运维人员，可以选择像Postgres, Google SQL (a hosted MySQL option) 或者 Segment Warehouses (a hosted Redshift) 这样的数据库，要优于Redshift, Aurora or BigQuery等。如果运维人员充足，可以选择Redshift等，为以后强大的扩展性做好准备。从另一个角度来说，分析半结构化数据是也是比较普遍的需求。这样就对数据科学家的技能提出了更大的挑战。面向对象的编程背景，精通Python/R 等语言也是对客户工程师团队的重要考量。

预期的数据分析的响应时间

比如像欺诈检测、系统监控等实时数据分析需要的数据分析相应时间有严格的要求。其他的数据分析比如像电子商务网站的用户留存分析等，并没有实时响应的严格要求。客户需要结合自己的用户场景，来选择合适的数据仓库。如果绝大部分的分析是基于已有的数据，对数据的实时性没有特别高的要求，建议用户选择像Redshift or BigQuery这样的数据库，对数据的读取和合并做了大量的优化。如果客户对实时性要求非常高，可以考虑非结构化的数据库方向和内存数据库方向。

当然，选择用什么样的数据库做数据仓储，只是第一步。以实时分析为例，需要从数据仓库，数据湖，计算引擎等架构方面做出通盘的考虑。

---