营销系统设计之适用范围数据

本文分析了当前营销系统中适用范围数据方案的痛点,主要集中在抽象的业务模型和数据库设计。作者提出了两种新方案,强调业务模型的重要性,讨论了方案一的优点(灵活扩展)和缺点(数据检索性能影响),以及方案二的相反情况。作者寻求行业专家的意见,促进交流学习。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景

最近工作不怎么忙,就梳理了下营销系统。结合业务现状以及自己的思考,本篇对【适用范围数据】设计方案做了一个设想,还望大家提出观点和意见,相互交流学习。

痛点

先说目前的【适用范围数据】方案设计有哪些痛点。 目前的方案设计主打一个抽象,从模型到数据库表可以说是高度抽象。

一张适用范围表存储了所有适用范围数据,通过类型加以区分。在业务层没有具象化的模型与之对应,业务模型依然是【适用范围】,也就是说一眼是看不出适用范围表达的是什么。

个人认为,数据库表是抽象的没有问题,但业务模型也是抽象的,在可读性,可维护性上个人觉得不太友好。

新方案

针对痛点,产生了两种新的设计方案,如下图所示:

方案一

方案二

两个方案的主要差别在于存储层。个人观点是系统设计应当聚焦在业务模型上,重业务模型设计轻数据库设计,当然轻数据库设计并不是说数据库表不重要,只是相对来说而已。数据库的设计只要能够满足业务需求,系统性能需求即可。

首先说方案一,隔离的适用范围业务模型和数据库之间的关系,数据库表是抽象的。

优点: 是当增加新的类型数据时,也就是增加新的业务模型,以及一个与之相关的存储适配层即可,无需建表。

缺点: 缺点还是比较明显的,每种类型的数据增长速度不同,数据放在一起,对于数据检索性能的影响是全局性的,若涉及分库分表的话,可能还会有如何选择合适的分片键的问题,分库分表方案可能会比较复杂。

方案二的优缺点其实和方案一是反过来的。

总结

望请大佬各抒己见,相互交流学习。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值