栏目导航
B端产品数据库设计的原则
发表时间:2019-08-13

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

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

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

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

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

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

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

  第一类是业务对象的属性字段,作为基本数据进行维护。如果这些属性字段在多个地方冗余,会导致基本数据更新的时候,需要更新其他表格大量的数据。

  一类是一些可以被其他字段计算出来的字段,如果这些字段也保存在数据库实体表中,会导致只要参与计算的字段发生变更的时候,都需要更新这个冗余字段,增加后台逻辑耦合度。

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

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

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

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

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

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

  维护多个产品版本成本很高,如果想要统一版本涉及数据迁移,用户教育等等,难度极大。

  现在都在努力挖掘客户数据的价值,如果数据库不统一,后续在做跨客户的数据分析或者统计的时候难度极大。

  老用户体验差,口碑很难维持。运营部门在客户服务的时候碰到极大难度,用户的流失率会大大增加。

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

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

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

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。香港马经今期开奖结果

 

友情链接:
Copyright 2018-2021 主页 版权所有,未经授权,禁止转载。