4

テンプレートに準拠したディクショナリ テーブル (少なくとも fields を持つ) とともに、importandステートメントを使用してデータベース内にデータ クラスターを格納することができます。exportMANDT, RELID, SRTFD, SRTF2, CLUSTR, CLUSTD

ディクショナリ tableと areaを使用して、内部テーブル全体を名前と IDta_testを持つデータ クラスタとしてデータベースに保存/取得する 2 つのステートメント例を次に示します。testtabTESTztestAA

export testtab = ta_test to database ztest(AA) id 'TEST'.
import testtab = ta_test from database ztest(AA) id 'TEST'.

テーブルの内容をztest見ると、次のレコードが表示されます (最初の 4 つのフィールドが主キーです)。

MANDT   200
RELID   AA
SRTFD   TEST
SRTF2   0 (auto-incremented for each record)
CLUSTR  integer value with a maximum of 2.886
CLUSTD  a 128 character hexadecimal string

また、この方法で保存されたデータの量は、内部テーブル内にあったデータよりもはるかに少ないことに気付きました (たとえば、内部テーブル内の 1.000.000 の一意のレコードは、ztestテーブル内の 1.703 レコードのみになります)。ステートメントを設定compression offすると、exportレコードの量は増えますが、それでもはるかに少ないです。

私の質問: これがどのように機能するかを知っている人はいますか? 実際のデータは別の場所に保存されており、そのデータへのztestポインタが含まれていますか? 圧縮？暗号化？実際のデータはデータベースから直接アクセスできますか (ABAP レイヤーをスキップします)?

4

1 に答える 1

3

データ クラスタの内部形式は文書化されていません (少なくとも公式文書にはありません)。私の経験からすると、これにはポインタだけでなくデータ全体が含まれます。テーブル エントリを別のシステムに移送するだけで (ALV リスト レイアウトを移送するときに頻繁に行うように)、内容を移動するのに十分です。さらに、バイナリ BLOB にはデータ構造に関する多くの情報が含まれていないようです。互換性のない方法でソース/ターゲット構造を変更すると、データが失われる危険があります。データベース レイヤーから直接アクセスすることはできません (これは、ドキュメント全体のさまざまな場所で実際に述べられています)。マーシャリング/アンマーシャリング アルゴリズムをリバース エンジニアリングすることは可能かもしれません。

于 2012-12-16T16:23:02.530 に答える