🚀 go-pugleaf

峯岸と申します。

#尾崎さんの求められている情報ではありません。
#ただ気がついたことを書いただけですので、あしからず。

尾崎　英一 wrote:
（中略） 
> 2.　対象データ件数が多い。たとえば１テーブルに１億行など。

これは、R/3というよりも使用するRDBMSの話しになるような気がします。
#R/3の使っているRDBMSといった方がいいのかもしれません。

１行１０バイトとしても、１ＧＢになりますからひとつのテーブル/表領域
でも物理設計の段階でＮＧではないでしょうか？
データの属性や何かで可能な切り口でパフォーマンスとの比較考量の上
分割するのがbetterかと...。ないしは、一定の期間で別媒体に待避させて
テーブルからは削除するとかして行を減らすとか、データはサマライズして
保有するとか...。
非常に大きな表領域は、あまりメリットがないように思われます。

> 3.　１日で終わるかわからないような大量検索がある。
> 4.　クライアントが全国にちらばり、かつその総数は数十から数百程

3を全国のクライアントからやられたらそれこそネットワークトラフィック
過剰で誰も検索ができないという状況が想定されるのでは？

あくまでデータ検索を例にもうしあげますが、
そういう時には、各サイト/拠点にreplica（必要なデータを抽出したもの）を作れば、
各クライアントの検索する総行数（全表検索になってしまった場合でも）も
へりますし、ネットワークトラフィックもLANに限定して考えればよくなるので
何かと都合がいいのではないでしょうか？先に述べたサマライズデータを検索に用いるとか。
どのようなシステムを構築するかにより要件も変わってくるでしょう。

いずれにせよ１日で終わらない検索よりもサマリでも例えば３分で検索できる
方がお客様はうれしいのではないでしょうか？（私見）

あとは、実際にSAP-JAPAN社のコンサルテーションを受けるかして詳細をつめて
いくしかないのでは？

お役にたてなくて申し訳ないです。
-- 
Takeshi Minegishi