树形结构循环遍历,简单来说两句

🔭提出问题

1️⃣有没有小伙伴在实战项目中处理数据时喜欢将其放在访问数据库查询语句上呢?大部分情况下如果我们不太喜欢处理逻辑结构的角度来说,确实直接暴力访问数据库查询是最简单明了的了。但是我们在树形结构循环中最好是不要这样子做哦,因为这样犯了大忌讳!

🔬问题抛出

2️⃣在树形结构中,最简单就是分两级就解决了我们在日常的项目需求。但是有可能树形结构方案需求那边的同事给你提出非常多的分支结构,底层构造需要来个三四层,你再底层循环中加入了不必要的访问数据库的操作,或者将查询得到的多条数据(例如:List集合),大概率你的接口返回值会大崩!!!

📚原因所在

3️⃣大家可以想一想,遍历一遍的情况,访问数据库应当还是在1秒以内,不受到什么影响,在往下到两层或许也是说得过去的,但是如果到了三四层的时候的?不敢想象了,下面遍历数都是用乘法来计算的,如果在数据库中的数据量非常大,你将访问数据库的操作放在了底层循环语句中,你想想估计每次的一次遍历过程都是数以千次或者万次以上来计数了,因为访问数据库到程序之间有延迟,访问速度可想而知,十秒之内都有可能没有数据产生,而且访问速度也比较吃你的计算机的性能配置了,性能差的都有想把电脑砸了的心思了,O(∩_∩)O哈哈~

🔑解决办法

4️⃣其实树形结构的解决办法没有想象中的那么难,主要是我们一定要养成好习惯,要避免多次访问数据库的情况,不管循环遍历多少次,我们访问数据库层面做到数次以内基本就能解决业务需求层面的基本问题了。在数据库表结构中,业务需求真正用到的表不会有很多,一般有一些联表查询,我们多写几个mapper层面的接口语句,什么数据我们不能得到呢?还有就是访问数据库语句我们一定要放在最顶层的循环语句外,其他的业务语句应该是基于最外层循环的层面来做才是最恰当的做法。内存速度是很快的,一次性将查询的结果放在java内存中访问,树形结构我们通过我们的逻辑来构造,慢慢将数据set到我们的支架中,访问速度杠杠滴!!!

💢💢💢例如下面的逻辑代码是错误的:

for(Demo demo : list){
	List<Demo1> list1 = demoMapper.select();
	for(Demo2 demo2 : list1){
		List<Demo3> list2 = demoMapper.select2();
		for(Demo3 demo3 : list2){
			List<Demo4> list3 = demoMapper.select3();
			//相关逻辑代码实现
			... ...
		}
	}
}

💖💖💖正确的逻辑代码应当是将所有的访问数据库操作放在顶层for循环之外才正确,例如如下代码:

List<Demo1> list1 = demoMapper.select();
List<Demo3> list2 = demoMapper.select2();
List<Demo4> list3 = demoMapper.select3();
for(Demo demo : list){
	//相关逻辑代码实现
	for(Demo2 demo2 : list1){
		//相关逻辑代码实现
		for(Demo3 demo3 : list2){
			//相关逻辑代码实现
			... ...
		}
	}
}

💊注意事项

5️⃣还有一点很重要就是我们要注重我们的逻辑思维能力,很多时候并不是我们自己做不到,而是没有想到正确的点子上。记住一点:“思路在前,代码在后!”,逻辑没有理顺,直接干代码,这样的代码很多时候都是需要重构的,所以大家在编程的时候尽量不要做无用功,思路和逻辑通了,可以得到事半功倍的效果。

🚴🚴🚴最后,祝大家代码写的都对,逻辑都能跑通,永无bug!!!

🍆路过的小伙伴,如果博文有帮助到你解决相关问题,可以点赞+收藏+关注一波呀~👊👊👊本人将会持续更新相关项目实战用例的博文,感谢您的支持哦!!!芜湖起飞✈️✈️✈️
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Fish_Vast

您的打赏是对我最大的支持!!!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值