数据的处理是在数据库中还是在应用程序中？
昨天和同学讨论，同学说数据库可以处理所有对数据的操作，并且这样做才是安全的；而我则认为，应该是应用程序把数据从数据库中取出后，应用程序进行数据处理，然后再将数据写入数据库。求指导。
------解决方案--------------------
目前的数据库确实能够做到大部分的逻辑都在数据库端完成。但在数据库中实现逻辑有下列问题：

1、数据库一般通过存储过程、函数等方式实现逻辑，这种方式代码很难维护、而且开发效率很低，特别比起java、.net等高级语言有优秀的ide时开发效率低得可怜；

2、不方便数据库移植，如果一个系统要从oracle移植到sql server。这时就是个灾难，基本等于重新开发；

3、在数据库中实现效率至少效率更高这句话也是个疑问，目前大点的软件都是应用服务器集群+主备数据库，

逻辑放到数据库中，无法高效利用应用服务器的资源，特别是并发高的系统，数据库本身就是性能瓶颈，如果

把主要逻辑都放到数据库，会导致数据库瓶颈更加严重。

基于数据库实现逻辑存在很多弊端，目前很少有大型软件把复杂的业务逻辑放到数据库中实现，一般只是把存

储本身的逻辑，如表的约束、级联删除啊等放到数据库中。
------解决方案--------------------
1 数据库执行数据操作的命令，比如SQL，PL/SQL(Oracle以外的也有类似的语言)，比所谓的高级语言要高效得多。开发效率低是程序员的水平低，和数据库没有关系。
要是写驱动，写协议，写传输的，不会数据库很正常，一个做数据库应用的不精数据库，不是开玩笑吗。

2 一个系统在没有数据库特定对象时(比如过程，触发器，包，序列，Lob对象)可以轻易的迁移到任何数据库，因为市面上的数据库只有一种：关系型数据库。
而且这个是个伪问题，为什么要迁移？自己做过的项目一万个里面有几个迁移了？如果因为面向多种用户的情况，本身就需要多种数据库支持，当初创建数据库特定对象的人，脑袋是被什么撞到了？迁移时候才想到？

3 只要是面对互联网的海量应用，都不应该把复杂的数据逻辑操作放到数据库里，这点是正确的。因为应用服务器可以非常轻易的扩容，从1台扩容到100台几乎是无损耗，分担压力的效果明显。而数据库服务器从1台扩容到100台，基本没有太大作用，分布式数据库的设计和开发都和传统的开发是有点区别的。
这个问题很好判断：你的项目需要几台服务器？如果数量是10以内，不要谈什么数据库的弊端了，老老实实把数据操作放到数据库里进行。
------解决方案--------------------