B端产品数据库设计的原则

本文结合实战经验，列举了数据库设计中一般容易犯的错误，以及产生的后果。

今天我们来说说B端产品失败的主要原因之一，产品的业务建模以及数据库设计不合理。

B端产品的数据库设计究竟有多重要呢？怎么说呢， 如果产品定位决定了一个产品有没有市场，那么数据库的设计很多时候决定了这个产品能够走多远的问题 ，数据库的设计合理性是一个产品好坏最重要的指标之一。关于数据库设计步骤以及规范的技术文章已经很多了，今天我更多偏产品以及业务层面来解释一下其重要性。

有些从C端转型来做B端的产品技术人可能会不以为然，数据库设计有这么重要吗？

实际上B端产品数据库设计的合理性要比C端产品数据库设计的合理性重要很多，C端产品一般来说业务相对简单，数据之间的耦合度低，很多用非关系型数据来进行支持，数据库的设计相对简单，即使前期设计不当，后期调整起来问题也影响不大。 而B端产品，业务复杂，数据关系联系也多，一般用关系型数据库来进行支持， 设计好一个复杂B端产品的数据库结构，难度是不小的。

数据库设计一般容易犯哪些错误以及产生哪些后果呢，我在这里说明几个常见的非技术规范方面的问题：

1. 数据表格中放置了大量的冗余字段

在TO C产品设计的时候，我们为了数据的读取速度，避免关联表格读取信息，表格里面放置大量的冗余信息字段。

在TO B场景中，往往数据量不如TO C,大多数情况性能不会成为瓶颈， 如果放置很多冗余字段，会导致后端逻辑的耦合度极其高，后续的可扩展性以及维护成本极高 （B端产品因为业务复杂，可扩展性以及可维护性是极其关键的指标）。这里面说的冗余字段主要包含二类：

• 第一类是业务对象的属性字段，作为基本数据进行维护。如果这些属性字段在多个地方冗余，会导致基本数据更新的时候，需要更新其他表格大量的数据。
• 一类是一些可以被其他字段计算出来的字段，如果这些字段也保存在数据库实体表中，会导致只要参与计算的字段发生变更的时候，都需要更新这个冗余字段，增加后台逻辑耦合度。

2. 属性字段关联的对象错误

属性字段需要和什么对象关联需要反复斟酌，比如说在ERP中，常见对象有商品，顾客，订单，库存等等，哪一些属性字段放在哪个业务对象是最合适？是否需要抽象出新的对象来放置属性字段，这里面衡量各种方案的一个原则就是， 看哪个方案最终可以让综合数据量最小，一般来说就是最佳方案 。

3. 对象之间一对一，一对多，多对多关系设置的错误

对应关系一旦错误，已经有客户上线之后，后续要调整，涉及到老客户的数据迁移，是极其痛苦的。常见的，比如说用户与角色的对应关系，如果用户角色前期设置了一对一的关系，在复杂业务系统中，用户权限复杂的时候，很有可能最终导致需要设置大量角色来满足用户功能权限的需求。如果允许一对多的关系，只需要配置几个可以组合成所有用户权限的基本角色就可以了。

4. 随意的增加字段

经常看到的模式，是需求人员拿到需求以后给到开发人员，说我需要一个什么功能，然后开发人员考虑一下实现方式，很随意的增加了几个字段。这个功能应该做吗（对于功能优先级的判断，请参考前面一篇文章《如何定义B端产品的MVP》上、下）？应该做成怎样才是最佳方案？数据库对未来业务的兼容性如何？这些内容都没有考虑，如此持续研发多年，离一个好产品就越来越远了。

这里有一个原则要注意的就是，数据库不要随意的增加字段，每个字段或者表格的增加要极其谨慎 ，因为对于产品来说，增加字段容易，对于老的版本兼容性是没有问题。 但是如果一旦增加了字段，后面要去掉或者调整，难度极大， 这里面的工作量包括用户数据的迁移，以及原来逻辑中涉及到需要调整的字段的部分。

另外对于SaaS产品来说，一些基本数据，比如说城市，户口类型，国家，以及一些国家，地方规定的政策等规则或者参数，这样的数据不要做成跟客户挂钩的数据，尽量做成跨客户的基本数据表，这样做好处， 一是数据可以统一，将来统计的时候极其方便，第二是如果需要更新，一次性更新就可以了，不需要一家家客户的去进行更新。

数据库的设计不当，会经常导致后续在面对新增业务的时候，很难用一套数据结构来支持多种业务情况，如果因此而产生了多个产品版本，就会比较糟糕了，会有如下后果：

1. 维护多个产品版本成本很高，如果想要统一版本涉及数据迁移，用户教育等等，难度极大。
2. 现在都在努力挖掘客户数据的价值，如果数据库不统一，后续在做跨客户的数据分析或者统计的时候难度极大。
3. 和外部第三方合作需要建立标准接口难度大。
4. 人员流动导致除了最新版本，没有人知道老版本的功能是怎样的。
5. 老用户体验差，口碑很难维持。运营部门在客户服务的时候碰到极大难度，用户的流失率会大大增加。

…….

上面的这些情况综合的结果， 上线的客户越多，最后产品越走不动，所有的研发力量只能进行版本的维护，以及小修小改 。当然这样的团队继续做大规模的产品开发，也是不太合适的。 如果已经产品面临这样的情况，应该怎样来应对，后续我们再来写对应文章进行分析。

最后要说的一点就是，现在很多公司的数据库设计都在放在下面的普通开发身上，对于这样核心关键的内容， 建议要最好的人类似DataArchitect的角色来把关，如果没有类似能力的角色，数据库的设计要经常有架构师，核心开发，产品经理等人组成小组来周期性的进行讨论和检查。

作者：李东林（微信公众号：SaaS产品说；微信号：jianguzhuxin），原ADP大中华区产品负责人，14年To B研发与产品设计，团队管理经验，主导过多款大型企业管理软件的设计、研发、上线，也有过2年移动互联网TO C的创业经验。

本文由@李东林 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash， 基于CC0协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: