微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

提升产品经理“技术思维”:学习数据表结构知识

来源: 300575

产品转技术难度比较大,学习数据表结构就门槛低很多,对产品设计的作用也很明显。本文会简单介绍一些产品设计中会用到的数据表结构方面的思考,希望对各位有所帮助。

提升产品经理“技术思维”:学习数据表结构知识

程序是怎么运行的呢?

简单来说,就是去指定的位置(表)取数据,完成运算,放到指定的位置(表)存起来或展示出来。

那么,怎么保证取到的/存到的数据是按我们预想的方式来的呢?这就涉及到表结构问题了。

数据表是由表名、表中字段、字段内容组成。本文主要围绕字段划分及字段定义两个部分,介绍在产品设计中需要用到的表结构知识。

一、字段分类

要完成一个流程(运算),我们需要诸多数据(字段),这么多字段是一张表还是多张表呢?

我们可以以商品上架为例,简单分析一下。

比方说,仓库现在还有可口可乐50个,进价2.5元,售价3.5元。

1号货架只剩5个可乐,小王在19/6/24日15:20:12向该货架上架20个,预计放在货架第4层;因为新货架促销,打折价3元。

首先,所有相关信息排列:

提升产品经理“技术思维”:学习数据表结构知识

实际业务会比这个字段更多,全在一张表里储存虽然看上去清晰,但是缺点也很明显——因为将主体相关的属性、流水、维度等数据全部混在一起,势必造成大量的数据冗余。

我们按数据类型拆为属性表和流水表。

其中属性表分为商品SKU和货架;流水表为上架操作过程。整理后如下:

提升产品经理“技术思维”:学习数据表结构知识

首先,看一下商品表:

(1)商品属性(类别,名称等)跟商品流水(进货、出货)混在一起,可以进一步拆分。

(2)“仓库剩余个数”,可能进货的要改、上架的要改、盘点的要改,多个地方都会对这个字段作用。这种情况可以通过实时计算,比写入覆盖的方式更为准确。

所以调整后会改为:

提升产品经理“技术思维”:学习数据表结构知识

注:前台展示的余量实时计算,不落表。

可以看到商品流通和之前的上架表非常类似,只相差一个货架编号。

假设我们把仓库看做一个大货架,设为0,两表合并整理后:

提升产品经理“技术思维”:学习数据表结构知识

再来看货架表,“商品种类数”适用实时计算,不落表。(类似前文仓库余量计算)。

还有一个问题非常突出——商品详情这栏内容特别多。

非结构化数据,不便处理,且与其他表内容重复(比如商品名称和售价)。同样的字段最好只在一个地方维护,避免表之间的数据冲突。商品名称很明显放在商品属性里。

那售价这个字段应该放在商品还是货架上的商品详情?

这其实跟业务模式相关,放在商品里方便全局管理,但是单个货架不能实现差别化定价;相反,放在货架上,同一商品在不同货架上可以设置不同售价,缺点是修改调整比较困难。

根据我们的业务情况,售价主要是统一管理,放在了商品属性;折扣主要是单个货架进行,所以折扣价放在了货架的商品详情。

调整后如下:

提升产品经理“技术思维”:学习数据表结构知识

数据结构确认之后,页面内容设计就比较清晰了:

【商品】

提升产品经理“技术思维”:学习数据表结构知识

【货架】

提升产品经理“技术思维”:学习数据表结构知识

【货架详情】

提升产品经理“技术思维”:学习数据表结构知识

【商品流转】

提升产品经理“技术思维”:学习数据表结构知识

注:在实际产品中,页面入口可能带有一些参数,比如上图如果是点击“进货”按钮的弹出框,就无需再手动选择交易类型。

二、字段类型

前面从大的范围上介绍了字段的划分,细节上单个字段的类型、长度也需要加以关注。

一些常用的字段类型:

提升产品经理“技术思维”:学习数据表结构知识

提升产品经理“技术思维”:学习数据表结构知识

提升产品经理“技术思维”:学习数据表结构知识

在字段类型上,我也遇到过一些坑,举两个例子说明一下:

我在P2P公司上班,用户会发布很多借款,有个字段是表示借款类型,比如listingtype。

我们绝大多数的标都是普通标,穿插一点点其他类型。总类型不超过5种,所以当时字段类型是tinyint,范围0-255。

后来有段时间我司发展与合作机构的合作标,当时我做配置系统,设计成每个合作单位分配一个listingtype。

跑着跑着有一天,研发反应过来了,说:总数就255,你再加就爆了。

后来的解决办法是将合作标统一一个listingtype,然后同一类型下,每家单位再各自分配一个sublistingtype。

再举一个例子,还是这个合作标的时候,上线之后,利息计算错误。研发查了一圈,是建表的时候利率字段用了默认的DECIMAL(18,0),导致导入数据时被四舍五入。

三、总结

当然,你可以说:表结构不是研发自定义的吗?但这也不能全是研发的锅,一是研发可能不清楚整个产品的规划,或者说随着业务变化,原本适合的字段类型变得不再适合。

另一方面,并不是所有产品都是从零开始,有的可能是后来加入进行老产品的版本迭代。这种产品在设计之前,了解原先的表结构及字段类型,就能避开很多坑。而且相比前端展示层,数据层上的坑,一般都是大坑,改起来也困难更多。

大家都知道,产品有技术背景会更方便沟通。技术入门也许太难,表类知识入门就简单多了。

本文抛砖引玉,希望大家能往此方向去提炼一下自己,相信会给产品工作带来较大助益。

 

作者:文二水,微信公众号:文二水

本文由 @文二水 原创发布于人人都是产品经理。未经许可,禁止转载。

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号