web数据库

web数据库这词听着唬人，据库其实拆开看就是据库浏览器加服务器再加一堆数据。十年前我还在用PHP写留言板的据库时候，压根没想过这玩意儿会变成今天这样。据库

那时候的据库web数据库，说白了就是据库MySQL往页面里塞数据。用户提交个表单，据库后端拼个SQL语句，据库查出来用foreach循环渲染成HTML。据库慢，据库是据库真慢。每次刷新页面都得重新查一遍库，据库碰上数据量大点，据库用户能盯着白屏抽完半根烟。据库但那时候大家都没得选，据库所有逻辑都堆在服务器上，浏览器就是个哑巴终端。

转折点出现在Ajax普及那会儿。突然之间，页面不用整个刷新了，后台悄悄跟数据库对话，前端拿到JSON再局部更新DOM。这感觉就像你本来每次买菜都得跑趟超市，现在超市开了个窗口，你喊一嗓子，人家把菜从窗户递出来。但本质上，数据库还是那个数据库，只是中间多了一层异步管道。

真正让我觉得变天的是Node.js和MongoDB那波潮流。JavaScript居然能写后端了，文档型数据库直接把表结构扔了。我2014年接了个小项目，用Express加MongoDB搭了个博客系统，写起来那叫一个畅快——不需要先设计表结构，存进去就是个JSON对象，取出来直接能用。但代价也明显，复杂查询得靠聚合管道，性能调优起来比SQL麻烦十倍。

再往后，Firebase和Supabase这类Backend-as-a-Service把数据库又推远了一步。前端开发者直接通过SDK读写云端数据库，连服务器都不用自己部署了。实时监听功能更是夸张——数据库里改个字段，所有在线用户的界面自动跟着变。去年我帮朋友做个协同编辑白板，用Supabase的Realtime功能，半小时就搞定了数据同步，搁五年前这得自己写WebSocket再维护心跳连接。

不过这里头有个陷阱。越方便的东西，越容易让人忽略底层原理。很多新手用Firebase用得飞起，问他数据怎么索引的，一脸茫然。我见过一个团队把全量用户数据都塞在Firestore里，每次查询都全表扫描，账单出来的时候人都傻了。web数据库再怎么包装，底层还是逃不过存储引擎、查询优化、并发控制这些老问题。

说个有意思的细节。现在Chrome DevTools里能直接看IndexedDB，浏览器自带的本地数据库已经能存几百MB数据。PWA应用靠这个实现离线访问，本质上是把数据库挪到了用户硬盘上。但同步策略又成了新麻烦——本地改了，云端也改了，冲突怎么解决？拿我常用的Notion举例，它用的是CRDT算法做合并，但大多数开发者根本没听说过这词。

数据库本身没变，变的是它和web的接口方式。从最初的CGI脚本拼SQL，到ORM框架自动生成查询，再到GraphQL让你精准取数，最后到现在的实时数据同步。每层抽象都在降低使用门槛，但也在增加调试难度。遇到个诡异的数据不一致问题，你得从浏览器缓存一路排查到CDN再到数据库主从复制，中间隔着七八层。

所以我的看法是：别被新名词唬住，也别迷信老一套。该用SQL还是用SQL，该上实时数据库也别犹豫。关键是搞清楚你的数据到底怎么流转的，瓶颈在哪。就像开车，自动挡确实省事，但你要是连发动机转速和档位关系都不懂，真在陡坡上溜车了，可能连手刹都忘了拉。