如何把握SQL与业务代码之间的交互

以前经常被两个问题困惑.....

假设一个页面需要多条数据（sql不同），怎样去操作更好？

1.ajax请求处理所有的业务，然后返回。

2.每一个所需数据都单独发送一个ajax，然后返回。

经过对业务的加深及测试，对比如下

第一种方案，降低了服务器压力（如果同时又1000万用户同时操作，第一种方案服务器压力相对来说更小）

第二种方案，加快了查询效率（相对于一个ajax请求执行多个sql操作来说，一个ajax请求执行一个sql操作效率更高）

sql与业务，是一对一好的关系好？还是一对多的关系好？

1.一对一

2.一对多

以前常听大佬们说，能用一条sql处理的地方就不要用多条sql处理。

经过三年的开发经验（额。。感觉自己目前只能被称作码农）感觉终于理解这句话含义：

一条sql如果能做多条sql能做的事，并且查询效率更高的情况下，这句话是符合的。反之，如果一条sql查询效率更低，则将其拆解成多条sql执行。

言归正传，其上对比如下

一对一，降低了耦合度，后期可维护性提高。

一对多，提高了可复用性，但是后期高耦合问题会越来越明显（比如根据业务修改了一个sql，造成其他引用异常，引发的连锁反应）。

因此，如果是绝对不会修改，或业务性不强相对简单的sql，一对多，灵活的运用封装，相对较好。（适合复用的下拉列表数据等...）

如果业务性较强，相对复杂的sql，一对一避免后期牵一发而动全身。（再次提醒能用一条sql处理的地方就不要用多条sql处理）