本帖最后由 雪候鸟 于 2014-2-25 17:33 编辑
adgjl 发表于 2014-2-25 10:19
你们现在公司的SAP程序还是像以前公司那么滥？
记得我以前说过的观点不，我个人只使用Select * FROM * ...
现在在公司不搞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我是懒得去数了。
gongminkate 发表于 2014-2-25 16:12
拜托，我又不是学info的，不用这么上纲上线吧，中国难道是靠在国外的中国人么...
不用回复了哈
好的，我不回复。{:5_319:}
德国人的思维模式只适合机械，汽车，it还得去外恶的米国。
本帖最后由 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，仅此而已。
adgjl 发表于 2014-2-25 19:07
明白了，咱们说的是两回事，我说的是SAP R/3而不是BI。
- 要知道BI数据表格基于星型结构，可以基本 ...
恩，sap的数据还是最好用FM，太多特殊规则了。
雪候鸟 发表于 2014-2-25 19:49
恩，sap的数据还是最好用FM，太多特殊规则了。
看高手过招！
Linux_Handy 发表于 2014-2-25 13:19
请不要拿淘宝这类东西作为例子。这些个上得了台面吗。
技术透明指什么技术，没人用就不发展了，你生 ...
那国内不是淘宝百度，难道还有别的家做数据库么？
雪候鸟 发表于 2014-2-25 13:47
数据库这东西还真不是什么人都能做，听起来简单做起来复杂。现在大多数数据库都学oracle的mvcc并发, 可是 ...
里面学问确实多了去了，但是不是说就搞不懂的东西，细节单独拿出来大家都能看得懂，而且很多都是优化，而优化其实主要还是人力和成本
数据库，还有操作系统，他们就是一个及其复杂的软件项目，要说德国中国做不出一个操作系统或者数据库系统，我不信，但是做出来一个没人用，这个是肯定的，这也正是为什么没人做的原因
本帖最后由 chinapope 于 2014-2-26 17:25 编辑
uiaxm 发表于 2014-2-26 16:53
苹果的操作系统比较完美漂亮吧,
就是苹果的定价太贵,
如果苹果能够便宜30% 到 80%.
你干脆直接说用苹果的人心灵最美！
它家东西技术上都是准一流，但感受一流。
adgjl 发表于 2014-2-25 19:07
明白了，咱们说的是两回事，我说的是SAP R/3而不是BI。
- 要知道BI数据表格基于星型结构，可以基本 ...
老哥做的项目里碰到上HANA的了吗，感觉如何