open sql的确不能发挥sql的全部性能，问题是你即使了解了数据库内部运作还能怎么做，还不是得用open sql？ ABAP本身就是业务层的语言，不是底层语言。
SAP也提供native sql提供更强大的功能，但是一旦你用到超出open sql之外的性能，就无法确保兼容性了。也许数据库打了某个Patch你的native sql效率骤降你要自己想办法，而使用open sql出了问题责任全在sap，你可以理直气壮地去找sap。所以我还是建议你不要使用超出open sql之外的任何性能，我也极少遇到某些性能问题必须用到native sql的，除非极端情况下要drop某个超大表格什么的，能节省些许时间，其实也未必值得。
我个人的经验是，一个程序使用Select越多越容易出错。老实说，我甚至很少使用Select语句，都是调用Class method，Function module去访问数据，坏处是你必然读出很多不必要的数据，好处太多了，以后的功能扩展会很容易，很多数据都是现成的，而且sap的function module经常会自动缓存相关数据，之后的访问会自动加速。更何况，没人能完整理解sap表格之间的全部关系，都是知道个大概罢了，调用FM读数据可以确保表格关系正确，以及hard coded逻辑也被执行。
adgjl 发表于 2012-9-13 14:52 static/image/common/back.gif
open sql的确不能发挥sql的全部性能，问题是你即使了解了数据库内部运作还能怎么做，还不是得用open sql？...
{:5_336:}
确实能使用sap的function尽量使用，我看sap表头疼，那缩写哎。实在不行我也是都是使用opensql的。就是使用opensql也不代表不需要考虑性能优化. 最近一个项目一个同事写的简单的嵌套查询，主查询对子查询使用exists. 我问你为什么使用exists不使用in, 他说看了一本sap优化的书说exists比in快。这句话大多数情况下成立，其实在他那个查询里in比exists快几百倍 。因为如果用exists, sap把那个opensql简单转为sql, oracle对那个sql不走索引。
本帖最后由 adgjl 于 2012-9-13 15:18 编辑
我很少使用Select，即使用也只使用最简单的查询语句，根本不用嵌套查询，一年用不了几次Join，因为很可能你Join的字段不走索引。所以对我来说不存在数据库类型和效率问题，有也是Basis需要关心的问题而不是我。我的字典里是没有Endselect的:-)
说白了，我只是偶尔使用select...from...into...where...的最简单结构，外加必要情况下for all entries in。连sort by，group by之类的零碎儿都不用（用ABAP的sort快的多）。你说我需要关心数据库类型和优化么？这种Select也不会出什么错误不是？
雪候鸟 发表于 2012-9-13 12:49 static/image/common/back.gif
bist du auch entwickler order berater?
专门忽悠人的berater
kleinlin 发表于 2012-9-14 10:16 static/image/common/back.gif
专门忽悠人的berater
好啊。你德语一定很牛
adgjl 发表于 2012-9-13 16:02 static/image/common/back.gif
我很少使用Select，即使用也只使用最简单的查询语句，根本不用嵌套查询，一年用不了几次Join，因为很可能你 ...
如果用的都是sap基础模块听却是不需要。我们这边在sap基础上开发很多自己的功能，很多自己定义的表，很多东西只能自己实现。不过我作为quereinstieger确实需要适应下。
adgjl 发表于 2012-9-13 16:02 static/image/common/back.gif
我很少使用Select，即使用也只使用最简单的查询语句，根本不用嵌套查询，一年用不了几次Join，因为很可能你 ...
你说的这个group by的问题，还是尽量给数据库去做。因为事先在数据库作group by返回来的数据会少很多，这样sap的内存压力，还有网络传输的压力都回小很多。order by呢让数据库作大多数也是有好处的，为什么呢，因为数据库大多数并不需要order by, 因为如果这个列上有索引，数据库可能根本不需要排序，按照索引结构btree的读取就是排序的。这样sap的压力又小了些，排序也是很消耗sap内存和cpu的操作。
我使用的算法从来不用group的数据，我也从不使用SQL的count之类的方法。每个程序员都有自己的编程风格和原则，你当然可以选择自己的方式。我的原则是宁可消耗SAP的内存和CPU资源也不消耗数据库资源。因为SAP的资源瓶颈可以很简单地通过增加内存，增加Server进行load balance解决，而数据库接口资源的瓶颈解决就不那么容易了。况且Sort一个内表对SAP来说耗用的资源可以忽略。现今的Server内存根本不存在压力，你知道现在内存多便宜吧？:-)
如果程序算法的设计合理，这些数据库资源根本不会被大量占用，所以与其改进数据库访问语句，不如优化算法。我改过一个Online Shop的产品库更新程序，几百万的数据进行嵌套查询和循环，运行时间3个小时，只能周末运行，我花了一个小时改算法，打破嵌套，改为线性处理，运行时间就减为5分钟。
提个小建议，你遇到编程任务的时候先想好算法，如何尽量避免一切Loop..Select..Endloop或者Select...Loop...Endloop...Endselect，（注意：很多Select是隐藏在Function Module里的）。SAP的标准FM可以例外。你做到了这一步，就值得庆祝一下自己的编程水平上了个很大的台阶。
adgjl 发表于 2012-9-14 14:18 static/image/common/back.gif
我使用的算法从来不用group的数据，我也从不使用SQL的count之类的方法。每个程序员都有自己的编程风格和原则 ...
你的算法的优化的观点我还是很赞同的，一个好的算法决定了程序的质量，这里暂不考虑软件工程方面的条条框框，代码可读性等问题。不过在内存管理方面，我还是会尽可能少的去占用，尽管内存现在已经很廉价了，但是一个占用大量内存的系统在启动和载入数据的时候还是相当慢的，如果能在数据机构方面有有些优化措施，我想这样会比较完美了。
adgjl 发表于 2012-9-14 14:18 static/image/common/back.gif
我使用的算法从来不用group的数据，我也从不使用SQL的count之类的方法。每个程序员都有自己的编程风格和原则 ...
观点认同，我也从不用select endselect然后循环的时候再select的做法，因为性能还不如join. 我倒不是从sap角度出发的，因为实际抓取几条记录的时间只是sql解析比8分之一. 数据库做解析的时候并发能力大大下降。我现在也都是尽量用FM{:7_436:}