kleinlin 发表于 2012-9-13 11:52 static/image/common/back.gif
ABAP只是我的hobby
bist du auch entwickler order berater?
sbtree 发表于 2012-9-13 11:51 static/image/common/back.gif
HANA有哪些技术亮点？与数据库系统本身的性能方面的技术相比有什么优势？继续接受扫盲
HANA 好像是内存型数据库。。。
雪候鸟 发表于 2012-9-13 10:04 static/image/common/back.gif
要是真能这样当然很好，那hana的意义不是战术级别的了，而是战略。看来sap想通过hana屏蔽物理数据库，来避 ...
现在的SAP就已经基本做到屏蔽物理数据库了，并不是绑定的。
作为Quereinsteiger你应该尽量忘掉你的数据库优化技术，让SAP自己优化。比如，你明知道使用Open SQL的时候指定某个Index访问速度会加快，但是绝对不要这么做，让SAP自己去选择Index，如果SAP选错了，交给Basis去处理。每种数据库都有自己的特别之处，比如MSSQL访问nonclustered index效率极低，应该避免使用，但是这都是SAP自己通过Note优化的东西，Developer不要插手。你访问数据库，只要通过Open SQL（而不是Native SQL），尽量访问Indexed Fields，这就足够了，其它性能上的缺陷，让Basis去处理。
ABAP语法最初是很简单的，大部分的ABAPer也不是Informatiker科班出身，但是他们懂得SAP的规则。你的同事可能不懂什么是页锁，但是他不会在Dynpro里面到处执行数据库变更。
虽然数据库迁移不容易，但是我也做过这种项目，从某种数据库改为另一种并且迁移全部数据。有朝一日SAP有了自己的数据库，这种大规模迁移也是很自然的。
本帖最后由 adgjl 于 2012-9-13 12:51 编辑
sbtree 发表于 2012-9-13 10:51 static/image/common/back.gif
HANA有哪些技术亮点？与数据库系统本身的性能方面的技术相比有什么优势？继续接受扫盲
Hana不是一个数据预读程序，而是个庞大的基于内存的数据库系统， 下面还有Index Server，Name Server，Statistics Server，Preprocessor Server和XS Engine，共同完成DBMS的各种任务。
这玩艺儿对程序员和用户来说不用太深究，你在业务层写ABAP指令读数据，SAP愿意从内存数据库读还是从物理数据库读和你无关。你只要大概理解HANA Server启动的时候把数据已经缓存到内存数据库里这个大概的道理就行了。
adgjl 发表于 2012-9-13 13:46 static/image/common/back.gif
Hana不是一个数据预读程序，而是个庞大的基于数据库系统， 下面还有Index Server，Name Server，Statis ...
读入多少比率的数据
我也不知道。
你对数据库很感兴趣啊，在SAP领域里，数据库表格大小，索引修正等等这是Basis的事情，不是Developer和Berater的事情。没必要在上面花费太大的精力。
adgjl 发表于 2012-9-13 13:30 static/image/common/back.gif
现在的SAP就已经基本做到屏蔽物理数据库了，并不是绑定的。
作为Quereinsteiger你应该尽量忘掉你的数据 ...
可能是改良版的maxdb吗
adgjl 发表于 2012-9-13 13:53 static/image/common/back.gif
我也不知道。
你对数据库很感兴趣啊，在SAP领域里，数据库表格大小，索引修正等等这是Basis的事情，不是 ...
我最近2年的不少业余时间都花在oracle数据库上了
本帖最后由 adgjl 于 2012-9-13 13:06 编辑
老实说，我给不同的客户做项目，绝大多数情况下根本不看客户使用的是何种数据库，因为和我无关。除非Basis要求我帮助改进效率瓶颈。
还是那句话，Developer无需知道数据库的任何情况，他只要只要Transparent Tabelle，使用Open SQL就够了。
很遗憾，你的那些数据库知识作为ABAPer大部分用不上 :-)，而且最好不要滥用数据库优化技术，因为这是SAP自己的工作。
本帖最后由 雪候鸟 于 2012-9-13 14:13 编辑
adgjl 发表于 2012-9-13 14:00 static/image/common/back.gif
老实说，我给不同的客户做项目，绝大多数情况下根本不看客户使用的是何种数据库，因为和我无关。除非Basis要 ...
opensql只是阉割版的sql，我感觉sap也对opensql没做太多处理就发给数据库了，这样对底层数据库的了解还是很必要的。这个和java程序员觉得有hibernate就不需要考虑数据库的问题都是一样的.
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:}
adgjl 发表于 2012-9-14 14:18 static/image/common/back.gif
我使用的算法从来不用group的数据，我也从不使用SQL的count之类的方法。每个程序员都有自己的编程风格和原则 ...
我觉得负载的这个东西权衡考虑了，是sap多受点罪，还是数据库多遭点难，其实都是整个应用的速度下降。平衡吧，谁适合做什么，谁就去干什么，还是找一条平衡之道更重要。
sbtree 发表于 2012-9-14 14:38 static/image/common/back.gif
你的算法的优化的观点我还是很赞同的，一个好的算法决定了程序的质量，这里暂不考虑软件工程方面的条条框 ...
同意你的观点。喜欢考虑内存的，基本都是玩c起家的。一般搞java的都不会考虑。我最开始玩汇编的，有时候1两个字节都得扣扣，太小家子气了。{:2_227:} 现在内存怎么大都是不够大，我对面同事刚才还发愁这事情呢，给一个用户分配3G内存跑应用还是崩溃，这要是几个用户一起上怎么办。{:7_453:}
sbtree 发表于 2012-9-14 13:38 static/image/common/back.gif
你的算法的优化的观点我还是很赞同的，一个好的算法决定了程序的质量，这里暂不考虑软件工程方面的条条框框，代码可读性等问题。不过在内存管理方面，我还是会尽可能少的去占用，尽管内存现在已经很廉价了，但是一个占用大量内存的系统在启动和载入数据的时候还是相当慢的，如果能在数据机构方面有有些优化措施，我想这样会比较完美了。
我在此处谈的不是闲着没事儿专门写消耗内存的程序，而是以消耗内存为代价减轻数据库的负担。因为一来内存便宜，二来skalierbar，三来将来一旦内存瓶颈是很容易解决的，四来，速度快得多。比如几百万的数据量嵌套查询非索引字段从耗费的时间上看是不太实际的，但是在内存里就可以用优化的算法替代查询，虽然耗用了内存，虽然也不是运转如飞。我理解你的美好愿望，完美的程序是既有优美的结构，可读性又好，效率高，占用资源还很少。可惜在现实当中，我们通常不是在好和不好的算法当中选择，而是在不好和更不好当中选择。
关于内存问题我觉得你过虑了，内存问题尽管存在，但永远不是大问题，数据库出了问题就是大问题。想想前面提到的HANA就知道了，SAP都愿意在内存中放一整个数据库（想想这个内存用量吧），我往内存里缓存点数据简直是九牛一毛。数据库的效率比内存低3个数量级，其提高是有限的，积重难返的效率问题几乎是无法解决的，除非推倒重来，最好压根别让它发生。起码我不会选择这样一种有潜在很难解决的风险的方案。
当然了，选择了有风险的方案也不代表风险一定会发生。对于特定公司来说，大部分公司数据量没有那么大，数据库效率问题会一直在可控范围内。但是我觉得这不是我们加重数据库负担的理由。
好无聊啊，飘过。。。。。
whatI 发表于 2012-9-14 22:08 static/image/common/back.gif
好无聊啊，飘过。。。。。
{:7_426:}
雪候鸟 发表于 2012-9-14 22:10 static/image/common/back.gif
能不能帮忙推荐一篇关于ABAP的基础知识的文章？ 我有一个Junior ABAP Entwickler的面试。
swordheartde 发表于 2012-9-16 10:57 static/image/common/back.gif
能不能帮忙推荐一篇关于ABAP的基础知识的文章？ 我有一个Junior ABAP Entwickler的面试。
SAP 有专门的培训教程。你给我留个信箱地址吧如果我能找到就给发一份
swordheartde 发表于 2012-9-16 10:57 static/image/common/back.gif
能不能帮忙推荐一篇关于ABAP的基础知识的文章？ 我有一个Junior ABAP Entwickler的面试。
或者你自己网上找找 BC400 和 BC401的资料，是schulung的编号
本帖最后由 swordheartde 于 2012-9-16 20:22 编辑
雪候鸟 发表于 2012-9-16 18:55 static/image/common/back.gif
SAP 有专门的培训教程。你给我留个信箱地址吧如果我能找到就给发一份
谢谢你的回复哈，不需要很深，很技术化的教材，我来不及看，也看不懂。因为本来就是Junior的位置，公司以后会提供schulung的。我以前只学过SAP的使用，只要懂得ABAP开发的基本概念和应用在面试的时候能回答的上就可以了。 如果你能找到一些基础的章节，就发给我看一下. 如果有德语的最好，网上找不到最近的教材下载，也没有德语的 ：）
我的邮件是 swordheartde@hotmail.com
uiaxm 发表于 2012-9-16 20:28 static/image/common/back.gif
好久都没有看见你发贴了.
找到工作也不说一下吗?
不是说还在面试了吗。。。{:5_313:}