センサー データをロードする場合、特に数値列が多数含まれる場合は、ビューでデータを適切な型 (INT、FLOAT など) にキャストすると、クエリのパフォーマンスが大幅に向上し、ストレージのオーバーヘッドが削減されます。このアプローチにより、数値データが効率的に処理され、不要な変換や VARCHAR などの非効率的なデータ型の使用が回避されます。

Teradata ワークロード管理のフィルターを使用すると、管理者はユーザー名、クエリ クライアント、その他の属性などの特定の基準に基づいて、特定の種類のクエリまたは接続を制限またはブロックするルールを定義できます。この場合、管理者はフィルターを使用して、アプリケーションのユーザー名を使用する特定のクライアントからのクエリを防ぎ、セキュリティ ポリシーを適用できます。
オプション A (Flex Throttle) は、クエリの同時実行性とシステム リソースを動的に管理するために使用されますが、ユーザー制限などのセキュリティ ポリシーを適用するようには設計されていません。
オプション B (ユーティリティ セッション) はユーティリティ セッションの数を制御しますが、ユーザー名に基づいてクエリ クライアントをフィルター処理するのには役立ちません。
オプション C (例外) は、特定のしきい値または動作に基づいてクエリ ワークロードの例外を処理しますが、ユーザーまたはクライアントの制限を直接適用することはありません。

Teradata Data Mover は、主に Teradata または Vantage システム間でデータをコピーおよび複製するように設計されています。一般的な使用例の 1 つは、データを災害復旧システムに移動することです。これにより、システム障害や災害が発生した場合でもデータが利用可能になり、高可用性とビジネス継続性を維持するための貴重なツールになります。
Hadoop へのデータのアーカイブと Hadoop システム間のデータのコピーは、Vantage を Hadoop やその他の外部システムと統合する Teradata QueryGrid などの他のツールに関連します。
アクティブ/アクティブ レプリケーションのために Vantage システム間でデータをコピーする場合は Data Mover が必要になる場合がありますが、アクティブ/アクティブ レプリケーションには通常、Teradata の Unity や QueryGrid などのより高度なリアルタイム同期テクノロジが必要になります。

WITH ADMIN OPTION 付きのロールを付与すると、受信者 (この場合はマネージャー) はロールを使用するだけでなく、管理することもできます。これには、マネージャーの要求に応じて、不要になったロールを削除する機能も含まれます。

スパース結合インデックスを使用すると、最も頻繁にクエリされるパラメータ (この場合は CustomerNumber) の条件に基づいて、テーブルから行のサブセットを格納できます。入力パラメータとして CustomerNumber を使用して Receiptline テーブルにスパース結合インデックスを作成すると、クエリはデータのより小さなサブセットに効率的にアクセスできるようになり、特に数百万の戦術的クエリが関係する場合に、パフォーマンスが大幅に向上します。
他のオプションは、この状況には最適ではありません。
Receiptline に NUSI を作成する: NUSI はクエリのパフォーマンスを向上させることができますが、複数の列 (例: ProductTypeId、OrderTypeId、VendorId) に NUSI を作成しても、CustomerNumber に重点を置いたこの特定のクエリを改善するのにそれほど効果的ではない可能性があります。
ALTER テーブル ProductType および OrderType: これらの小さなテーブル (55 行と 175 行) にスパース マップを使用しても、パフォーマンスの向上という点では大きなメリットは得られません。問題はこれらのテーブルではなく、より大きな Receiptline テーブルにあるためです。
グローバル一時テーブルを使用する: 一時テーブルでデータを事前にフィルタリングすると、特定の状況では役立つ場合がありますが、これにより複雑さとメンテナンスのオーバーヘッドが増加します。また、スパース結合インデックスと比較して、必ずしもパフォーマンスが大幅に向上するわけではありません。