1）理念的区别
从sql或存储过程开始设计的开发，是面向关系型数据库的，后来面向对象开发兴起，人们发现面向数据库和面向对象思维方面不太一致，匹配有障碍。就出现了ORM，希望以面向对象化的思维设计程序，然后通过这个ORM工具，映射到关系数据库中。
ORM的目的，就是先设计对象，然后再映射到关系数据库，终极目标就是希望软件开发的过程，完全以面向对象的方式来设计。一个完美的ORM，即使开发者完全不会数据库也可以使用。当然，终极目标和完美境界，都是不存在的。
2）实际的作用
ORM在实际开发中带来的帮助，我觉得主要还不是面向对象的设计方式的变革，而是它作为一个引入的中间层，带来了额外的好处：
a）大多数数据库操作都更加方便简单了（许多人都离不开ORM，就是因为极度的方便）
b）更不容易犯数据库操作中的一些低级错误，比如重复的sql查询、比如大量的注入***漏洞等等
c）屏蔽了数据库的差别，可以支持多种数据库
c）屏蔽了数据库的差别，可以支持多种数据库
……
而在实际开发中，缺点也很明显，就是关系数据库最擅长的复杂查询，ORM明显力不从心，不仅仅是wojilu ORM，凡是有经验的ORM使用者，比如hibernate方面的开发人员，一般也不会用ORM做复杂的查询。
关于存储过程，特别谈一下我的看法。
如果关注过微软出的一些示例程序，发现都是把复杂的业务逻辑放在存储过程中，中间层只要简单调用一下这个存储过程就可以了，代码看起来非常清爽整洁。但许多人认为(包括我)，它有几个缺点：
a）过于依赖数据库，甚至可以说，这种开发方式，基本上在微软的特定数据库上绑定死了。也可以说，这种开发方式的出发点，很大程度上是有利于微软的商业利益的。
b）存储过程不利于维护和业务逻辑的复用、分解和重构。你是数据库高手，也许不觉得什么，但对于水平不等的其他程序员，维护或调试修改其他人的存储过程，往往是一场灾难。
c）虽然存储过程的重要优点，是提高性能，但在实际场景中的后果却是阻碍了性能。具体讲，相对于sql，存储过程虽然有那么一些性能优势，但因为绑定死了特定数据库，反而不利于数据库的垂直分区和水平分区。同时，海量数据下，大量使用nosql数据库(非关系型数据库)等其他方式的存储，已经是必经之路，存储过程成了这方面巨大的障碍。
最后，我觉得ORM应该是一个必备工具，但它不能代替原生的数据库操作，在复杂的查询需求下，sql或存储过程还是很有必要的。我觉得以ORM为主，辅之以sql或存储过程，是比较实用的策略。