数据模型和数据库表的关系

在传统web服务中,数据库表通常与Java模型一一对应。然而在处理复杂筛选需求时,这种方式变得受限。例如,优惠活动的多种限制条件导致无法通过单一数据库查询获取所需数据。面对变化的需求,采用代码实现查询而非依赖数据库,使得问题得以解决。活动中涉及的限制信息和收益规则可以分表存储,并在运行时生成。这种设计思路强调,Java类设计应先于数据库表,避免让数据库成为系统设计的瓶颈。这次经验提醒了作者在解决问题时不应过度依赖工具。
摘要由CSDN通过智能技术生成


 还是之前的整合优惠活动的项目所总结的经验。

问题

传统的web服务,都是通过数据库实现增、删、改、查,model层的javabean,一般都会和数据库某个表一一对应。但这个项目中,我无法通过数据库的查询,实现筛选我想要的数据。

         比如一个优惠活动,他有N类限制条件,如酒店名称、入住日期是星期几、刷的信用卡是哪个银行组织,用户是那个等级的,等等。

         好吧,这样看还不是很麻烦。当项目进行到一半,发现需求变了,一个优惠活动,有多个收益项目,积分、折扣、代泊车、送电影票,每个收益的限制未必相同。

         于是我就坐蜡了。

         解决办法

         穷则变,变则通。当我决定不使用数据库的查询时,整个世界豁然开朗。

         因为数据量并不大,才几百个,所以我觉得第1期版本直接用代码做查询(后期可以考虑搜索引擎)

         设计类图(简介版):

 

 

 

         这里,活动信息,收益限制类信息,都可分表保存,在生成活动时从数据库提取数据,生成限制类(内部有判断规则)

        

         结论

         类似依赖倒置原则。Java类的设计,要优先于数据库表的设计,数据库只是为系统提供服务,而不应该成为限制系统设计的障碍。

 

         这段经历,对我在技术上没什么提升,带在分析解决问题的思路上敲了一记警钟。我以前太习惯于传统的web后端开发,在思想上太过于依赖工具。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值