演出
ほとんどの環境で「ETL/ステージング」が別のステップとして行われている理由は、2 つのエンドポイントがやや硬直的であり、データ操作に適したプログラミング言語がないためだと思います。つまり、TXT、CSV、XML、JSON、または SQL があり、それを別の形式/スキーマで必要とする場合、誰かが「変換」を行う必要があります。ただし、GemStone で作業している場合は、Smalltalk で変換を行うことができます。別の手順は必要ありません。
ファイル
ファイル (TXT、CSV、XML、JSON など) がある場合は、GsFileを使用します。実際、他のエンドポイントがファイルを処理できる場合は、1 つのソースから合意された形式でエクスポートし、別のソースにインポートするだけです (GemStone が変換の「重労働」を行います)。ファイルはより単純で、通信層を回避し、デバッグを簡単にします (ソースがファイルを作成していない場合、それはソースの問題です; 保留中のディレクトリにある場合、まだ処理していません (宛先の問題) ); 完了したディレクトリにある場合、宛先はそれを処理しています)。
このアプローチでは、GemStone で (1 つ以上の) バックグラウンド ジョブを開始して、ディレクトリを監視し、読み取り用にファイルを開き、ファイルを処理してから、別のディレクトリに移動します。基本的な文字列操作以外は、GsFile を操作するだけで済みます。次に、データベースでオブジェクトを作成および更新します。
ODBC
GemStone から ODBC ライブラリ (または、GemConnect で行われるようにデータベースのネイティブ ライブラリ) への FFI 呼び出しを行うことは可能ですが、これはおそらく不必要に複雑になります。代わりに、外部システムとの相互作用が改善されたツールを使用して、別のレイヤーを作成します。このレイヤーはテキスト ファイルを書き込んだり (上記のように)、適切なインターフェイスを使用して、GemStone と直接通信したりできます。私の傾向は、Dolphin を使用してデータを抽出し (優れた ODBC サポート)、Dolphin から GemStone に直接通信することです。他のクライアントの Smalltalk ダイアレクト (Pharo、VA、または VW)、または別の言語 (GemStone への Python インターフェイスに取り組んでいる学生がいます) で同様のことを行うことができます。
O/R マッピング
ここでも、ある形式のデータを別の形式に変換する方法が必要になります。これらは高度にドメイン固有である傾向があり、Smalltalk コードを記述するだけの方が簡単です。あるいは、Pharo 、VA、VW などでGLORPのようなものを使用することもできます。
ベストプラクティス
GemStone で ETL の「ベスト プラクティス」を見つけられなかったと思います。それは、私たちが外部プロセスまたは別のステップと考えているものではないからです。ファイル (GsFile)、ソケット (GsSocket)、ライブラリ (CLibrary)、またはクライアント (GCI) と通信する方法があります。ここから、複数のプロデューサーと 1 つのコンシューマー (RcQueue)、または 1 つのプロデューサーと複数のコンシューマー ( locking ) などの内部処理の問題を見ることができます。
したがって、GemStone アプリケーションが ETL を実行しないわけではありません。内部で実行するだけであり、状況はより状況に固有のものです。