产品经理该不该设计数据库表?(产品经理mysql)
并不是所有的产品经理都是懂技术的产品经理,那么让产品经理来设计数据库表,是否合适呢?这篇文章里,作者表达了他的观点,并阐明了观点提出的背后原因,一起来看看吧。
前段时间,读友群里有朋友吐槽产品经理设计表多次给开发挖坑,引起了群内读友的大讨论,产品经理到底该不该设计数据库表?
其实这个问题也不仅仅只有他们公司存在,估计很多公司也存在产品设计数据库表的情况。我曾经接手的项目,就是产品设计数据表,研发根据产品设计数据表创建数据库表开发。我当时感觉到很震惊,还有这么干的?
产品经理很多是不太懂技术的,他们设计数据结构,程序开发同学能用吗?估计也会像上图的朋友所说的,错位处理吧。好无奈啊!
在我负责的技术团队,数据结构的设计是一件非常高层次的工作,一般只有架构师和资深工程师才能参与,我技术评审最核心的内容就是数据库的设计。
所以,我先表达一下自己的观点:产品经理不应该设计数据库表!具体原因,我们接下来分析。
一、表单和表不一样
产品经理做产品设计,不可避免的会涉及到大量的业务表单,对于系统,特别是企业级的系统来说,大部分的业务都是通过业务单据的流转来体现的。
以一个老人的生活状况评估表单为例。
从产品的角度来说,表单不仅是业务数据的体现,而且充满了用户的交互体验,视觉体验,还有数据规则的校验。所以表单是用户视角的元素,是为用户使用系统来处理业务使用的。所以产品经理在数据化表单的时候,一般会向开发呈现如下的数据表说明。
在数据库设计层面,表结构虽然来源于产品设计的表单,但如果完全参考产品经理甚至是产品经理来定义表机构,很容易造成直接将表单翻译成表的情况,如下图:
但实际我们在数据库设计中,数据表和表单并不是完全一致的。
表单的作用是采集数据或者展现业务数据,只需要考虑业务需要即可。而数据库表的作用是存储数据和管理数据的,数据存在查看,新增,更新,删除等操作,在这个过程中要保证避免脏数据、错误数据、重复数据等情况的发生,还要考虑存取数据的性能和效率。
所以数据表设计需要考虑数据库范式,需要适当做数据冗余,需要设计辅助字段等等。
如上图所示,一个老人基础评估表单可能涉及的数据结构,是由三个表组成,甚至更多。而且为了配合程序更好的使用,需要补充一些非业务型的数据字段,如红色部分。为了更好的管理枚举属性的字段内容,还需要引入数据字典。
因为表单和业务关联,所以不同的场景,不同的人群,甚至不同客户的个性化需求,表单内容会随之调整,但是数据结构作为整个应用系统的底层架构,它是需要稳定的,最好是以不变应万变的。
下图数据结构为了扩展性的需求,很有可能将基础评估表里的那些评估内容,抽象成一个通用的数据结构:评估模版表(evalution_form_tpl)、评估问题表(evalution_form_question),从而可以扩展制作各种各样的评估表单。然后用评估表(evalution_form)和评估结果表(evalution_form_reply)来存储评估数据。
表单是具象的,而数据结构是抽象的!
这就是自定义问卷的最简单结构!通过这个结构我们就能支持各种各样的评估表的功能,从而可以开发一个适应业务能力更强的系统或者产品。
最后总结一下表单和DB表的区别:
二、跨层兼任不可取
从前文分析我们也知道,表单不同于DB表,产品经理设计更多的是表单,而不是表。但是为什么还是有很多公司,让产品经理来负责设计表呢?
粗略分析,有以下几个原因:
- 产品或者系统中的表单反应了业务的数据结构,产品经理直接以此确定数据结构,不用做两遍工作,比较高效。
- 产品人员具备一定的技术背景,能同时兼任产品和数据结构设计工作,合一起做,提升效率,节约成本。
- 企业对于产品经理的职责定位不清晰导致,赋予的职责范围过大。
首先,我们先来分析,产品经理做DB表设计是不是本职工作。我们还是从一个产品或者系统的组成来看:
从这个分层结构上来看,产品经理的主要本职工作处在这个分层结构的第一层,有更具象的功能模块组成。而数据建模层要在倒数第二层,和产品功能层相差较远,显然应用表现层上的主要内容才是产品经理更加核心,更本职的工作内容。
为什么数据建模层不能成为产品经理的核心本职工作?我们都知道在企业里一般都有兼任的情况,第一是领导兼任下一级岗位的,第二是平级岗位间兼任的,很少出现跨级兼任的情况!
每个相邻层级之间,因为相互依赖,相互支持,对对方领域会更有了解和理解。相邻层级里兼任部分工作,从工作关联度上来说和专业度上来说,都更比跨级领域要高。所以,如果数据建模没有专门的人和团队负责,交给相邻层的技术团队也许会更加合适。
就像前文的那个数据结构,技术团队可以融合技术选型,比如可以采用MongoDB作为评估表存储,用redis缓存xx数据,应用支撑层的相关技术的使用,这些都会影响数据建模层的设计。所以数据建模需要依赖下层数据层的技术选型,需要充分考虑上层应用支撑层的技术实现,这些都是绝大多数产品经理都无法胜任的。
而对于技术出身的产品经理,像老谭这样从开发到架构都做过的产品人员,做点数据建模是完全可以胜任的。但是不是胜任就要去做的,我们要明确自己角色的转换,我现在是一名产品经理,我的工作和精力要更贴合业务,更贴合用户,而不是考虑技术实现。
更何况,我们不再做技术,很难深入技术细节,跟不上最新的技术趋势,我们设计的DB表很难思考全面,照顾周全,所以可以参与讨论,但不能具体负责。
综上所述,产品经理跨层负责DB表设计,我认为并不是非常合理的选择!你觉得呢?
专栏作家
菜根老谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发,擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议.
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
版权声明:
作者: freeclashnode
链接: https://www.freeclashnode.com/news/article-592.htm
来源: FreeClashNode
文章版权归作者所有,未经允许请勿转载。
下一个:系统聊天群(聊天群群)
热门文章
- 11月15日|20.1M/S,Shadowrocket/Clash/SSR/V2ray免费节点订阅链接每天更新
- 11月21日|20.9M/S,SSR/Shadowrocket/Clash/V2ray免费节点订阅链接每天更新
- 11月29日|18.1M/S,SSR/Clash/Shadowrocket/V2ray免费节点订阅链接每天更新
- 11月28日|19.7M/S,V2ray/SSR/Shadowrocket/Clash免费节点订阅链接每天更新
- 11月27日|19.2M/S,SSR/Shadowrocket/Clash/V2ray免费节点订阅链接每天更新
- 11月24日|22.5M/S,V2ray/Shadowrocket/Clash/SSR免费节点订阅链接每天更新
- 11月23日|22.6M/S,Shadowrocket/V2ray/Clash/SSR免费节点订阅链接每天更新
- 11月22日|21.3M/S,V2ray/Shadowrocket/SSR/Clash免费节点订阅链接每天更新
- 12月3日|21.7M/S,Shadowrocket/Clash/V2ray/SSR免费节点订阅链接每天更新
- 11月30日|18M/S,Clash/V2ray/SSR/Shadowrocket免费节点订阅链接每天更新
最新文章
- 12月13日|22.8M/S,Clash/SSR/Shadowrocket/V2ray免费节点订阅链接每天更新
- 12月12日|19.2M/S,V2ray/SSR/Shadowrocket/Clash免费节点订阅链接每天更新
- 12月11日|18.9M/S,V2ray/SSR/Shadowrocket/Clash免费节点订阅链接每天更新
- 12月10日|21.8M/S,SSR/V2ray/Clash/Shadowrocket免费节点订阅链接每天更新
- 12月9日|20.5M/S,V2ray/Clash/Shadowrocket/SSR免费节点订阅链接每天更新
- 12月8日|21.5M/S,V2ray/Clash/Shadowrocket/SSR免费节点订阅链接每天更新
- 12月7日|18.5M/S,SSR/V2ray/Clash/Shadowrocket免费节点订阅链接每天更新
- 12月6日|19.9M/S,SSR/Shadowrocket/V2ray/Clash免费节点订阅链接每天更新
- 12月5日|18.5M/S,Clash/SSR/Shadowrocket/V2ray免费节点订阅链接每天更新
- 12月4日|21.8M/S,Clash/SSR/Shadowrocket/V2ray免费节点订阅链接每天更新