5

グローバルアプリケーションのユーザーアカウントを使用してデータベースAにアクセスしています。このユーザーアカウントには、データベースAのスキーマを変更する権限がありません（つまり、テーブルの作成、テーブルの変更など）。このユーザーはデータベースBにもアクセスできますが、ビューのみです。SQLを実行して、データベースBのビューからデータベースAのテーブルにデータをフィードする必要があります。

完璧な世界では、次のSQLを使用できます。

create database_a.mytable as (select * from database_b) with no data

ただし、ユーザーはデータベースAにテーブルを作成できません。selectステートメントのDDLを取得できれば、個人アカウント（データベースBにアクセスできない）でログインし、データベースでDDLを実行できます。テーブルを作成するためのA。

他の唯一のオプションはSQLを手動で作成することですが、特にコピーしたいこのビューにはさまざまなデータ型とサイズの列が多数あるため、これは行いたくありません。

編集：私は近づいているかもしれません。私はこれを試しました：

show (select * from database_b.myview)

ただし、ビュー自体で使用されるすべてのテーブルのDLLと、ビューの定義が生成されました。selectステートメント自体のスキーマが必要なだけなので、これは実際には役に立ちません。create table asつまり、上記のステートメントを使用した場合に生成されるものが必要です。

Robのために編集：おそらく「DDL」は使用するのに間違った用語でした。を使用show view db.myviewすると、ビューが表すスキーマではなく、ビューの定義が表示されます。上記のの例ではcreate table as、selectで返される結果セットのスキーマを模倣するテーブルを作成する方法を示しています。テーブルを作成するためにバックエンドでDDLを生成し、そのDDLを実行して実際にテーブルを作成します。show table db.newtable次に、新しいテーブルのDDLを言って確認できます。そのDDLをselectステートメントから直接取得して、コピーし、アプリアカウントからログアウトして個人アカウントにログインし、DDLを実行してテーブルを作成できるようにします。

これは、特にソースビューに非常に多くの列があるため、時間を節約し、入力エラーを減らすために、手動でDDLを入力する必要があるという頭痛の種を節約するためだけのものです。とは言うものの、DBAを起動したり、動的な処理を実行するための洗練されたストアドプロシージャを作成したりすることは、私のニーズにとっては少しやり過ぎだと思います。selectステートメントから直接テーブルスキーマを作成するためのDDLを取得する方法が必要だと思います。

4

1 に答える 1

11

オブジェクトのDDLステートメントを生成します。

SHOW TABLE {DatabaseB}.{Table1};
SHOW VIEW {DatabaseB}.{View1};

ビューの列の内訳：

HELP VIEW {DatabaseB}.{View1};

ただし、ターゲットデータベースにオブジェクトを作成する機能がなけれDatabaseAば、あまり活用できません。明らかに、オブジェクトがすでに存在していた場合、INSERT INTO SELECT ... FROM DatabaseB.Table1またはオブジェクトMERGE INTOがすでに探索したオプションである場合。

代替ソリューション

提供されたビュー名に基づいてテーブルを動的に作成するストアドプロシージャを作成することは可能でしょうか？グローバルアプリケーションアカウントには、プロシージャを実行するための特権が必要です。通常、ストアドプロシージャを作成するユーザーには、ストアドプロシージャに含まれるアクションを実行するためのアクセス許可が必要です。（Teradata 13.10では、これによりいくつかの追加の柔軟性があります。）

このアプローチにはいくつかの注意点があります。数百から数十億のレコードを参照できるビューを具体化しようとしています。これらは、ターゲットテーブルの上に配置される単純な1：1ビューではありません。ビューを具体化するためにターゲットデータベースで必要なスペースを決定しようとするのは困難です。パフォーマンスは、ビューの複雑さとデータ量によって異なります。これは、高速パスまたはデータブロックに最適化された操作ではありません。

DBAとして、私はその意図を完全に理解することなく、グローバルアプリケーションアカウントによって採用されているこのアプローチに関心を持っています。このシステムをサポートするために関係するDBAとのオープンなコミュニケーションがあると信じています。ここでは明らかにできないあなたの狂気の理由があると確信しています。

考えられる解決策-揮発性テーブル

CREATE TABLEの暗黙的な特権がグローバルアプリケーションアカウントから取り消されていない限り、このソリューションは機能するはずです。

揮発性のテーブルはパーマスペースを必要としません。テーブル定義はセッションの期間中持続し、テーブルに挿入されるデータは、それをインスタンス化したユーザーのスプールスペースに依存します。

CREATE VOLATILE TABLE {Global Application UserID}.{TableA_Copy} AS 
(
   SELECT *
     FROM {DatabaseB}.{TableA}
)
 WITH NO DATA
   NO PRIMARY INDEX
   ON COMMIT PRESERVE ROWS;

SHOW TABLE {Global Application UserID}.{TableA_Copy};

と呼ばれるTeradata13.10機能を使用することを選択しましたNO PRIMARY INDEX。デフォルトでは、CREATE TABLEASはSELECTステートメントの最初の列を取得し、それPRIMARY INDEXをテーブルの列にします。これにより、データの人口統計によっては、テストでスキューとパーマスペースの問題が発生する可能性があります。PRIMARY INDEX基になるデータを理解しているので、自分で明示を指定できます。（構文が不明な場合は、DDLマニュアルを参照してください。）

ON COMMIT PRESERVE ROWSこの例の目的でのの使用は、おそらく無関係です。CREATE TABLEただし、実際には、テストのためにそのテーブルにデータをポップした場合、Teradataモードでは、揮発性テーブルに対してまたはその他のデータ操作が実行された直後にデータが失われるため、有益です。

于 2012-10-16T22:55:02.113 に答える