如何快速建立业务模型并抽象化以及在数据建模和性能方面需要注意的事项

首先声明,本人所有博客均为原创,谢绝转载!

在我们的工作中,需求的具体实现逻辑往往是不明确的,一般都是老板或者产品甩过来一个页面或者要求,剩下的就要靠我们自己去思考了,而建立业务模型,往往就是开发中最难也是最烧脑的一步.很多人可能想许久都不知道一个业务该怎么实现,或者是先想清楚了,但做着做着就发现之前的逻辑是错的,又只好重新改.

但是,这个过程对我来说则并不是很困难,因为我掌握了较为正确的数据建模的思考方式,下面我就以最近做过的评论模块和权限模块两个案例来说下怎么样才是我认为合理的业务建模的思考方式.

首先说下评论模块(在我的博客 https://www.cnblogs.com/yangfeiORfeiyang/p/9184412.html 里有评论模块的展示):

关于评论模块,可能不像各位都有需求文档之类的非常详细的叙述业务需求的东西,当时我做这个的时候我们领导就甩给了我一个微博评论的截图,然后让我按照上面做(没有听错,就只有一张截图,甚至连前端都是我自己写的)

类似于这张

当然要注意的是,新浪微博这个其实是典型的一级回复,而我当时要做的则是要有二级回复的,也就是一张报表底下有一个评论区,然后A评论了,那么此时他是一级评论,而如果B评论了A,那么此时他则是二级回复,当然此时如果有个C,那么他也可以去评论B,但是此时在页面显示上不会再出现一个独立评论区,而是会在A的评论区下面出现C回复B:

oK,拿到需求了,那么此时我们要干的第一件事情是什么呢?分析业务,数据库建模(也就是建表设计字段)

首先我们来分析业务:

既然是评论,那么我们首先需要将评论这个对象模型化,我们建立一个表remark,而评论有哪些属性(字段)呢?

1:一条评论是人发出的,那么肯定需要跟user表进行关联,加一个字段userId

2:人发出的东西是什么呢?是字符串,而且我们需要确保每条评论不能太大,要不然很容易出现刷屏的现象,当然,这个我们会在前端和服务器端进行把控拦截和验证但是数据库中也同样要保证不会出现这个问题,所以我们不能用text或者blob这种没有长度限制的类型,而应该设置定量长度并且数据空间可伸缩的varchar

3:我们还需要知道这个评论什么时候发的,所以需要加上字段createTime

4:评论是可回复的,并且有一级和二级之分,而且还有回复人,那么此时我们需要加上一级回复id,oneReplyId和二级回复人id,twoReplyId

5.因为评论有时候可能涉及到和谐因素,所以我们需要保留,哪怕被删了,也不能物理删除,只能逻辑删除,所以添加字段flag;

6.考虑到报表评论功能的专业性,需要添加一个审核字段,留着后期功能拓展使用,添加字段 isCheck;

Ok,差不多这样就能满足我们的需求了,大家这里应该可以看到,其实我完全可以再建立三个冗余字段userName,oneReplyName和twoReplyName,这样查数据的时候就很轻松了,如果你这样想,那就死定了,因为大家注意一下,userName也就是用户昵称是一个可更改的数据,而如果我加了这三个字段,那么为了保证数据同步,我就必须要在

用户更改昵称的地方,将我现在的评论里所以与其关联的评论的昵称也全部修改,这样会导致,这个人如果发了一千条评论,或者被一千个人评论过或者自己评论的加别人评论的超过一千条,那么我只是改一个用户昵称就需要改掉一千条数据!!!关于怎么建立良好可维护的冗余字段我后面会单独讲.还有,使用好合理的缓存,就不必担心因为关联而需要产生的多条sql语句

现在评论已经完事了,那么我们再来看看这个点赞功能,首先,点赞肯定是一个单独的模型(表),因为一个用户可以对多条评论点赞,一条评论也可以被多个用户点,所此时这个点赞表其实就是用户和评论的一个多对多关系中间表.(请注意,如果没有点赞功能,那么用户和评论之间是一对多的关系)

理清了关系,那么我们再来看下如何建立:

1.首先建立dianzan这个表模型.

2:因为点赞是由用户发出的,我们必须要知道是哪个用户,所以建立一个字段userId

3:因为用户是对评论进行点赞的,所以需要建立一个字段remarkId

但并不是建好表插入数据就够了,大家想一下,点赞和取消赞,这两个功能其实是非常频繁的,关键是他还不是非常关键的业务数据,如果因此就浪费掉我们数据库宝贵的TPS实在是可惜,所以我们需要在项目启动的时候就将点赞的数据全部加载到缓存中,之后对于点赞功能的操作全部都要在缓存进行,如果是Redis的话使用hash数据结构即可,如果是MangoDb或者ehcache这种

key value的单一缓存中间件和插件的话,将KEY设置为用户ID加评论ID,Value设置为Map即可,因为用户ID加评论ID是能保证每个点赞的唯一性的,所以散列结构的时间复杂度妥妥的O(1).还有要注意:点赞功能只有添加和删除,没有修改这种事情.最后关于点赞缓存的更新问题,在晚上的时候用定时器批量更新即可.

好了,到这里基本上评论的数据建模就完成了,关于权限那块,因为要讲和分析的东西太多,所以今天没时间讲完了,留着下次吧!最近在玩前端,各位如果有认识的比较厉害的前端小姐姐,可以介绍我认识下哈.当然,真的只是讨论问题.

原文地址:https://www.cnblogs.com/yangfeiORfeiyang/p/9310813.html