notion 的 database 设计思路

[liuser666]

细细想来，发现 notion 的 database 的设计可以异常简单呀。

以 mysql 作为后端举例：

一个 database 就是一个 json，每行的数据用 list 保存，全局的标签啥的顶层属性放个数组就 OK 了。

多人协同就编辑人数超过两人的时候后端维护一个 object 就行，都断线了再写回数据库。

转 csv 转 Excel 都容易。

性能问题也不用担心，json 转 object 以后想怎么操作怎么操作。

前端应该没什么难点，数据库 MySQL 只需要一个表。

酱，各位大佬觉得呢？

[kop1989]

如果是一个大学大作业级别的 notion，估计这样的设计差不多。
但你仍然把一些具有难点的地方通过一句 OK 、不用担心来一笔带过了。

比如：
多人协作时如何同步与防止冲突提交？
“都断线了再写回数据库”怎么操作？
服务器端靠内存支撑，内存爆了怎么办？内存泄漏了又怎么办？

[billzhuang]

光冲突解决，就比较麻烦。

[liuser666]

@kop1989 我想我单纯说的是这个 database 的设计问题。更多的是想大家想想这个思路是否有大的毛病而不是延展开来把其他系统的问题归结过来。多人协同这个冲突问题还凑合，内存爆了在 database 设计的考虑范围之内吗？其他任何的设计不都要考虑内存的问题吗？关键是采用 json 费不费内存，事实上不费。而且转为对象以后和其他方案的内存占用我觉得是不相上下甚至更少的（反驳请拿证据），json 里存的都是必要数据。还是说您想让我从 sql 数据库上亿数据的分表问题说到 js 的内存回收机制？再说回到冲突解决的问题，database 的冲突比编辑器的问题好解决多了，每行的数据都有独立性，每个人编辑之前先去服务器拿锁就完事，编辑完了再释放锁，最简单的 lock 锁就能解决。

[leonme]

@liuser666 说实话冲突解决目前业界都没有完美的方案……你这轻描淡写的

[liuser666]

@leonme 还挺有意思的，您把问题放大了，我说的是针对这个 database 的冲突解决问题，您谈的却是业界宏观的大一统冲突解决问题。我说的是特例情况，你说的是一般情况。特例有完美的解决方案，一般则还没找到，这不冲突。