每当产生一笔交易，交易双方的推荐人都将获得交易总额1.5%的提成。举例：比如张三与李四产生一笔交易，那么张三的推荐人将获得交易总额1.5%的提成，李四的推荐人也一样获得交易总额1.5%的提成。
交易产生后，要计算各相关人员的收支情况，反映收支变化。有两种方法实现：
第一种方法：主要在IIS服务器中进行运算
通过SQL把张三推荐人查出来，通过SQL把李四的推荐人查出来，一次交易中，各相关人员的收入和支出统统给计算好，然后写好SQL存入数据库。
第二种方法：主要在数据库服务器中进行运算
先在数据库中定义好存储过程，只需要传递进来交易双方的用户名和交易总额即可，然后存储过程根据定义，自己去查找张三李四的推荐人，自行计算各相关人员收支，自行更新或存储数据。
两种方法都可以实现，但是对比一下。
第一种方法，必须要几次进出数据库查询数据出来，然后在网站的后台代码中通过SQL事务来操作。
第二种方法，由于数据库中已经定义好存储过程，所以网站后台代码只需传递几个参数给存储过程即可。
请问各位，你们喜欢用哪种方法？哪种方法效率更高更可取？
我一直都是用前一种，但是我又觉得第二种应该比较节约数据传输的耗时。用第一种方法，如果我理解得不错的话，当我们鼠标点击下去后的二三秒内，客户端和数据库之间会产生多次打开关闭，因为要读取各相关人员的各种信息，才能计算分配好各人员的收支。
现在我想改用第二种方法，但是我又吃不准，搞不清楚到底哪种方法才是最好最科学的选择，所以特地来请教各位大哥。
谢谢！
7 个解决方案
#1
显然是第二种
#2
这个就应该是传说中的软件复杂度守恒定律？ 不知道了（个人的思想仅限于现实实现）不能从更高一个层次给lz建议
#3
就加减乘除，根本就不用考虑速度问题！你那个主要应该考虑安全问题吧，第一种方法容易出问题的，取进取出难免不出问题哈。第二种方法多好啊，什么事务啊触发器啊都是数据库服务器内置的东西，不用白不用！
#4
就加减乘除，根本就不用考虑速度问题！你那个主要应该考虑安全问题吧，第一种方法容易出问题的，取进取出难免不出问题哈。第二种方法多好啊，什么事务啊触发器啊都是数据库服务器内置的东西，不用白不用！
#5
第二种
#6
呵呵，真的是不太清楚，不过还是要幢比废话几句：
1）IIS 当你 找 张三与李四 的 时候，你因该可以“同时”拿到它们的推荐人id，然后 update 就可以了
2）第二种 可以把前端的问题简化，应该是越简化约好吧
1）IIS 当你 找 张三与李四 的 时候，你因该可以“同时”拿到它们的推荐人id，然后 update 就可以了
2）第二种 可以把前端的问题简化，应该是越简化约好吧
#7
数据库中快多了
#1
显然是第二种
#2
这个就应该是传说中的软件复杂度守恒定律？ 不知道了（个人的思想仅限于现实实现）不能从更高一个层次给lz建议
#3
就加减乘除，根本就不用考虑速度问题！你那个主要应该考虑安全问题吧，第一种方法容易出问题的，取进取出难免不出问题哈。第二种方法多好啊，什么事务啊触发器啊都是数据库服务器内置的东西，不用白不用！
#4
就加减乘除，根本就不用考虑速度问题！你那个主要应该考虑安全问题吧，第一种方法容易出问题的，取进取出难免不出问题哈。第二种方法多好啊，什么事务啊触发器啊都是数据库服务器内置的东西，不用白不用！
#5
第二种
#6
呵呵，真的是不太清楚，不过还是要幢比废话几句：
1）IIS 当你 找 张三与李四 的 时候，你因该可以“同时”拿到它们的推荐人id，然后 update 就可以了
2）第二种 可以把前端的问题简化，应该是越简化约好吧
1）IIS 当你 找 张三与李四 的 时候，你因该可以“同时”拿到它们的推荐人id，然后 update 就可以了
2）第二种 可以把前端的问题简化，应该是越简化约好吧
#7
数据库中快多了