|
|
本帖最后由 adgjl 于 2014-2-25 19:09 编辑
雪候鸟 发表于 2014-2-25 17:30
现在在公司不搞sap了，但是在BI这个团队，总是有数据要从sap里导出来的，间接听说abap开发那边程序错误很多。
join从程序正确角度来说，经常是必须的。假设一个vertrag表和vertragsposition的表， 如果在时间点A先select vertrag表，再时间点B select vertragsposition表，然后在程序里做join. 这里就存在一个时间差的问题. 在A到B之间，就可能有新的vertrags position删除或者加入，不符合你要的是时间点A的一个客户某个vertrag的信息，也不符合数据一致性的原则(除非你的事务都是serializable的，不过没几个商务系统这样做，因为并发性太差)。如果A和B是通过join一起返回的，这就没问题。
我们这边的主数据库实际上90%OLTP + 10%OLAP, 因为经常要做些实时业务分析，所以join 20几个表的查询也是常见。有些BI分析工具自动产生的sql, 光SQL文本就超过半兆字节，就是说巨大的SQL, 到底多少join多少group by我是懒得去数了。
明白了，咱们说的是两回事，我说的是SAP R/3而不是BI。
- 要知道BI数据表格基于星型结构，可以基本保证join的都是Key或者Index字段，而R/3里面则很少能Join到全是Key或者Index字段。BI本身就是为了Join存在的，要不海量数据就没法分析了。你可以想象一下，如果不基于Key或者Index字段join四五个百万级别的表格，就等着喝咖啡去吧。
- 即使在R/3里面，你说的对我来说也是为数不多的例外，我顶多只根据Key来Join你说的Kopf和Position的表，但是这我用的都不多。因为通常程序还会用到其他相关数据，你只能一个接一个Select下去。其实SAP提供了无数多的FM，我都是调用SAP的FM去Select（并不是说我不调用数据库，而是不自己去Select）。因为除了Kopf和Position的表，其他很多表格关系相当复杂，很多关系甚至是FM的代码Hard coded的。比如Positionspartner你读出来没用，SAP通过代码自动继承Kopfpartner，所以你要找Positionspartner需要连同Kopfpartner一起读出来，如果你不知道SAP代码规定的这种关系，你的数据逻辑就错了（数据不完全）。而你通过FM读出来的数据，也许有你不需要的，但是表格关系是由SAP自己来保证的。所以我的程序自己写不了几个Select，都是调用FM的。
我一般用Join都是偶尔访问某个Key的Texttabelle读一下Kurztext，仅此而已。 |
|
简体中文
繁體中文
English
Deutsch
发表于 2014-2-25 17:30
