前些日子，公司着手研发一款自用桌面软件。这款软件对数据库性能和存储量有着较高的要求。要在本地存储超过10万件商品数据，同时还要支持增删改查功能。在数据库的选择过程中，问题频出，各种难题让开发者倍感烦恼。
线下数据库成必然选择
公司专注于开发桌面软件，且要求用户在本地独立安装并使用。线上数据库因接口限制，无法适用，效率极低，故不考虑。我们需寻找适合的线下数据库来满足需求。线下数据库与软件在本地环境融合更佳，能保障软件的独立性及数据操作的高效性，不受网络波动等线上问题影响。开发团队从一开始就明确了这一点，这是走向正确方向的第一步。
在数据库的选择范围内，每一款都适合进行离线本地操作。这是基于软件的整体设计规划，选择范围已经得到了缩减。然而，即便如此，选择的过程仍然颇为曲折。
Rxdb的尝试
RxDB是一款适用于多种环境的客户端数据库。它的安装和初始使用过程相对简便，初期在开发阶段似乎颇具潜力。然而，随着数据测试的深入，问题逐渐显现。使用JavaScript批量导入数据时，一旦达到五万条，速度便明显下降，查询效果更是混乱不堪。这样的性能表现根本无法满足软件存储十万以上数据的需求。尽管初期表现尚可，但面对大量数据时却力不从心，给项目开发带来了极大的不确定性，最终只能选择放弃并寻求其他解决方案。
团队对Rxdb抱有期待，因为它的安装和使用过程确实很简便。然而，如果连数据库最关键的性能都无法达标，那么即便操作简便也是徒劳。这其实是在给开发者一个警示：不能仅仅因为初期的小便利就断定一个数据库适用，必须经过大量的数据测试才能做出判断。
Browser自带数据库的问题
浏览器自带的数据库无需安装即可使用，大家原本以为这样可以节省不少麻烦。然而，经过测试发现，一旦数据量增大，速度就会变得非常缓慢。性能不佳的问题完全掩盖了其便利性。虽然在小数据量下或许还能应付，但面对十万以上的数据量，这种缓慢的性能将严重降低软件的使用效率。
此时，开发者才明白不能仅凭免安装这样的表面优势来判断，任何再怎么好用的工具，若不能完成核心任务，在项目中的应用就毫无价值。开发团队还需继续寻找合适的数据库。
Node-gyp安装问题
安装其他数据库时，遇到了node-gyp的问题。这看似简单，但若不提前安装好环境，就会遇到麻烦。更糟糕的是，有时它会错误地显示找不到环境变量，而实际上环境变量明明就在那里。这种让人摸不着头脑的错误，真是让人气愤。还有，它会报错说无法识别“2.0”版本的工具，实际上应该使用“4.0”版本，不得不重新安装。这种频繁出现的错误，有些还难以理解，对于新手来说，更是让人头疼不已。
更要命的是，安装过程中出现了问题，原因在于系统用户名必须是ASCII码格式。结果，由于当时设置了中文用户名，这个错误让整个晚上都陷入了困境。大家这时都深感开发过程中充满了陷阱，一个小的疏忽就能影响到整个项目的进度。
sql.js性能不错
sql.js是个让开发团队感到欣慰的发现。安装过程简单，更关键的是，它的性能比Rxdb和浏览器自带的数据库都要出色得多。尽管之前遭遇过几个数据库的种种麻烦，sql.js却给大家带来了希望。然而，它并非完美无瑕，在打包过程中就遇到了将文件打包进软件的难题。需要通过在.json文件中进行配置来解决这个问题，但至少在性能上它是满足要求的。
发现了sql.js，团队仿佛看到了项目的希望之光。只要能够解决打包文件的问题，这个数据库就有可能成为软件数据库的最终选择。
# 安装sql.js
npm install sql.js
数据库orm选择
具体到数据库的ORM，网上有很多开源项目可供查找。我个人更倾向于单文件ORM，这可是开发过程中需要明确的关键点。一个优秀的ORM框架，能更高效地处理数据库操作，对软件开发至关重要。尽管之前已经确定sql.js的性能很出色，但若没有合适的ORM，数据库的全面功能可能还是受限。
let fs = require("fs");
let sql = require("sql.js");
let filebuffer = fs.readFileSync("db/subway.db");
// 记载数据库
let db = new sql.Database(filebuffer);
let sql = "SELECT * FROM `tables` WHERE user_id = 1 ";
let resp = db.exec(sql);
在整个开发阶段，选择合适的数据库显得尤为关键。你是否在开发软件时也遇到过让人头疼的数据库选择难题？期待大家的评论、点赞和分享。
