数据的处理是在数据库中还是在应用程序中？

Question

昨天和同学讨论，同学说数据库可以处理所有对数据的操作，并且这样做才是安全的；而我则认为，应该是应用程序把数据从数据库中取出后，应用程序进行数据处理，然后再将数据写入数据库。求指导。

Answer 1

目前的数据库确实能够做到大部分的逻辑都在数据库端完成。但在数据库中实现逻辑有下列问题：1、数据库一般通过存储过程、函数等方式实现逻辑，这种方式代码很难维护、而且开发效率很低，特别比起java、.net等高级语言有优秀的ide时开发效率低得可怜；2、不方便数据库移植，如果一个系统要从oracle移植到sql server。这时就是个灾难，基本等于重新开发；3、在数据库中实现效率至少效率更高这句话也是个疑问，目前大点的软件都是应用服务器集群+主备数据库，逻辑放到数据库中，无法高效利用应用服务器的资源，特别是并发高的系统，数据库本身就是性能瓶颈，如果把主要逻辑都放到数据库，会导致数据库瓶颈更加严重。基于数据库实现逻辑存在很多弊端，目前很少有大型软件把复杂的业务逻辑放到数据库中实现，一般只是把存储本身的逻辑，如表的约束、级联删除啊等放到数据库中。

Answer 2

1 数据库执行数据操作的命令，比如SQL，PL/SQL(Oracle以外的也有类似的语言)，比所谓的高级语言要高效得多。开发效率低是程序员的水平低，和数据库没有关系。
要是写驱动，写协议，写传输的，不会数据库很正常，一个做数据库应用的不精数据库，不是开玩笑吗。2 一个系统在没有数据库特定对象时(比如过程，触发器，包，序列，Lob对象)可以轻易的迁移到任何数据库，因为市面上的数据库只有一种：关系型数据库。
而且这个是个伪问题，为什么要迁移？自己做过的项目一万个里面有几个迁移了？如果因为面向多种用户的情况，本身就需要多种数据库支持，当初创建数据库特定对象的人，脑袋是被什么撞到了？迁移时候才想到？3 只要是面对互联网的海量应用，都不应该把复杂的数据逻辑操作放到数据库里，这点是正确的。因为应用服务器可以非常轻易的扩容，从1台扩容到100台几乎是无损耗，分担压力的效果明显。而数据库服务器从1台扩容到100台，基本没有太大作用，分布式数据库的设计和开发都和传统的开发是有点区别的。
这个问题很好判断：你的项目需要几台服务器？如果数量是10以内，不要谈什么数据库的弊端了，老老实实把数据操作放到数据库里进行。

Answer 3

1、在数据库中开发效率低是基本的事实，因为java、.net的集成开发环境已经很成熟了，而数据库一直没有一个像样的集成开发环境，oracle还有一个plsql还算好用，像mySQL、sqlServer呢，基本上很难调试成千上万行的代码。这和程序员的水平确实很大关系，但企业需要考虑资源问题，能在oracle中写出几千行逻辑代码的程序员很少，有代价也很高，而java呢普通大学毕业生就行了。2、关于数据库库迁移也是经常的问题，我做的是电力行业软件，有些电力公司只能用oracle数据库，有的只能用db2数据库。而软件功能是一样的，只是数据库不一样。如果你的逻辑写在数据库中，你就去哭吧。而我们使用ormapping工具进行持久化，迁移的代码非常低。

Answer 4

比较通用的逻辑 我一般都放到数据库里的？因为是oracle的数据库,平台兼容性比较好,所以我都是在数据库实现部分逻辑的。
别的数据库不太清楚.
不过数据库迁移确实是件痛苦的差事,因为各个数据库虽然是关系性的数据库,但是体系结构不一样,会出现各种各样莫名其妙的问题。

Answer 5

看实际的需要!~照楼主说的,如果仅仅是处理数据,当然是在本地草完了之后再写入进去为佳,这样服务器压力也小.但,有一些情况,最好是在服务器端进行处理!能够减少很多麻烦~比如:有一个很大的关联查询(很长很长的SQL命令),查询完了之后要根据这个查询生成一张新的大表(很大,要时间),这样的操作最好是直接扔给服务器,让它自己跟自己草..
放在本地的话,在生成的时候(一行一行地写入地话),万一本地忽然一下停电了,那张表才造了一半,你就麻烦大了去了!!!~~
这样的情况还不如直接使用那条sql,直接交给服务器,让它自己去建表.所以,个人以为,一切都要以实际需要来作决定..