一招搞定活字格的数据库选型

0级 最高级：甲方要求
如果存在甲方要求，选用甲方指定的数据库；
甲方未指定、自研项目、甲方指定数据库明显不合理，存在技术风险的情况时，进入 1级


1级 正高级：事环因素
事环因素是事业环境因素的简称，这是一个项目管理的术语。如果项目是一个大系统的组成部分，依据上级/上游 系统的数据库解决方案并使用外联库构型。
独立系统：跳转到 2级

2级 副高级：法务风险
判断是否存在法务风险，即使用某个数据库后，有可能存在被告侵权的风险。如果存在风险，则排除 Oracle 和 MS-SQL Server 等商用数据库软件，使用免费数据库软件。
如果不存在法务风险，跳转到 3 级


3级 中高级：项目预算
高预算、高法务（钱多事多）：Oracle 或 MS-SQL Server ，跳转到<结束>。不建议采用 My-SQL 、 PostgreSQL 等免费数据库软件或 Sqlite 、 Access 文件型关系数据库软件（甲方出钱了）
高预算、低法务（钱多事少）：跳转到 4 级
低预算，高法务（钱少事多）：My-SQL 或 PostgreSQL，跳转到<结束>。听哥一句劝，屁事儿倍儿多的甲方，别给他用 Sqlite。你不用跟我说 Sqlite 性能如何如何，你需要做的是跟甲方解释，并且要让甲方保证最后能给你顺利结款，我对 Sqlite 的看法不重要，一点儿也不重要。
低预算、低法务（钱少事少）：跳转到 4 级


4级 次高级：数据产量
每天产生（新增）的数据量 D 有多大
极小：D < 1000，跳转到 6级
可观：如果每天产生的数据量大于 D（D=1000，1K），则排除 Sqlite 、 Access 等产品，跳转到5级。D的值可依架构师的职业判断，但是不建议超过10K（每日新增1万条数据），如果达到这个量级，则单表年数据量将达到300-400万行，查询压力较大，未来性能压力和重构压力均大


5级 普高级：部署环境
项目允许使用云数据库：My-SQL，<结束>。
项目独立部署数据库服务器：
Windows Server：MS-SQL Server，Oracle，跳转到6级
Linux：My-SQL 、PostgreSQL，跳转到6级


6级 崇高级：数据安全
项目对数据安全要求高：跳转到5级
项目对数据安全要求低：Sqlite，<结束>

7级 人才级：人力资源
会哪个用哪个

<结束>
==================
附录：资源传送门

全国五级行政区划数据（2022年最新）

贡献一个网站模板

分享一个 Excel 公式大全，免费下载

《活学格用》[ 2021-12-08更新至1.0.5 ]

活字格插件检索手册（附下载文件）[更新至1.10 / 2022-03-01]

开源一个配色方案，祝贺 7.0 Update 1 成功发布

dystar001 发表于 2022-4-1 22:00
补充一下，还有一个选择：SQL Server Express。

SQL Server Express 是由Microsoft所开发的SQL Server ...

，确实，把Express 给忘了，还是实践得太少

补充一下，还有一个选择：SQL Server Express。

SQL Server Express 是由Microsoft所开发的SQL Server的其中一个版本，这个版本是免费且可自由转散布（需经注册），并且可和商用程序一起使用的小型数据库管理系统，它继承了多数的SQL Server功能与特性，像是Transact-SQL、SQL CLR等，相当适合使用在小型的网站，或者是小型的桌面型应用程序。

从技术栈来讲，一个小型的开发小组很难匹配各类数据库，所以我们的经验是：
项目小，预算少，用SQL Server Express，项目大，自然预算多，用SQL Server。这样只要只要掌握一张数据库知识就可以了。（客户有指定要求例外）

如果一开始项目小，用SQL Server Express（最大数据库文件支持10G），数据多了以后，可以转成SQL Server，只要保证数据库ip和数据库名不变，就可以直接迁移的，活字格的源程序都不需要重新编译。

终于看完了大佬的详细热心的回答，总体感觉是，有点明白是怎么回事了，晚上要多吃几碗饭。古话讲的好，合久必分，分久必合，原来数据库也是怎么玩的。

夏雪冬阳 发表于 2022-3-25 16:35
小白问个问题：日积月累的情况下如果数据量慢慢变大，性能慢慢变差的话怎么处理呢，是不是可以将以前的数据 ...

我来解释2点

1. 软件的生命周期
所有的软件都有生命周期，我是说所有的。到一定的时间后，系统重构几乎是必然的，因为前端的业务变了。一个系统，能有个5年的生命周期就可以了，好的8年，更牛逼的有10年吗？谁敢说他的系统十年没重构过？是地球人设计的吗？

所以，差不多了该重构就重构，别总舍不得，重构了性能更好，速度更快，价值更大，别总纠结在那点研发费用，不畏浮云遮望眼，风物长宜放眼量，别怕重构，只要货好，能创造更大的价值，重构是个好事儿。

2. 从数据库的解决方案上，面对这种情况，通常是采用分库分表的方法来解决性能的问题。

分库就是如你所说的，将以前不会再用到的数据分到另外一个库中，这样生产库的负载就轻了，但是并不是如你说的备份储存后将其删除，备份后从库中删除，你就真的查不到了，而分库技术，通过数据库路由调度，保存在历史库中的数据还是有办法查到的。

如果数据量大只是集中在某几个表上，那也没有必要分库来搞，只要把数据量大的几个表拆开就行了，有两个办法，一个是横着切行，简单说就是按数据产生的时间切开，比如一年分一个表，另一个是竖着切列，你别以为只是行上的数据会增长，随着时间的推移，很可能会加列的，而且有可能列会越来越多的，列太多了也很影响性能的，所以也可以竖着切列，这就要看具体的表是什么情况了。

当然了，比较常见的是横着切行。横着切这种情况，咱们用活字格，其实只要稍做修改就可以了，比如在查询数据时，如果查询时间比较久远，可以在查询按钮上绑命令判断一下，在交互上跟用户说一声：您查询的记录太过久远了，系统正在整个档案室中为您翻找，请稍候...
然后实际上页面已经跳转到绑定历史表的页面上去查询了。

当然这样搞比较鸡贼，查询的历史结果和当前结果合不到一块儿去，这也可以考虑用 执行SQL命令生成临时表等技巧来解决，还有其他的办法，有很多。

比如，咱们这个论坛，你最多只能翻到第100页，再往后就翻不了了，但其实数据还是在的，你用论坛的搜索功能，搜索一个年代比较久远的贴子，点开来后，就能突破翻页的100页的限制，这些，都不是将数据备份储存后删除可以做到的。

假如，项目一开始用的是 Splite 数据库，慢慢数据量变大了，需要换 SQL Server 了，用活字格简直不要太方便了，直接复制成外联库就行了。

还有一种情况，就是万一你碰到了高并发了，这就要搞分布式了，万一，我是说万一，真的碰到这个情况了，数据量又大，还高并发，你还是上云吧，活字格云连程序带数据库都给你解决，这事儿胡爷就给你办了完全不用你操心。

可是万一——云也不行，那就太点儿背了啊——你的项目还是私有化部署，不能上云，军政警油、电通银财，那咱们再想办法，这种点儿背的事儿解决起来也不是一句话两句话能说清的。

然后，但凡你能预见到你可能出现“三分天下”（分布、分库、分表）的情况，表上除了ID，别忘了再放个UUID字段（GUID都一样，本质上是一回事），将来三分天下时，你就知道当初加这么个字段该有多明智了，提前给您提个醒，勿谓言之不预也。

小白问个问题：日积月累的情况下如果数据量慢慢变大，性能慢慢变差的话怎么处理呢，是不是可以将以前的数据备份储存后将其从系统中删除。

说的明白

精品 感谢大佬