1

最初に言っておきますが、ペンタホについて私が知っていることは、1 つの段落を埋め尽くすことはありません。私はPostgreSQLについてより知識があります。私は、私の会社のために Pentaho (v. 4.5) で一連の月次レポートを作成しているいくつかの請負業者と協力しています。一部のデータは ETL プロセスを通過し、レポート作成のためにロールアップする必要があります。dba(ish) の観点から、これらのテーブルを別の PostgreSQL スキーマに移動したいと考えています。

Pentaho は MySQL (スキーマを持たない) でよく使用されることを知っており、これが問題を引き起こすのではないかと心配しています。私はいくつかの「グーグル」を実行しましたが、このトピックについて多くのヒットはありませんでしたが、数年前からクローズドバグを見つけました- したがって、機能がサポートされるべきであることを意味します.

これを行う前に、これが失敗するか悪い考えであるかを誰かが知っているかどうかを確認したいと思います。(または、うまく機能している場合は、それも教えてください)。

最後のメモ: 私は PostgreSQL 9.1.5 を使用していますが、これを自分でテストするための Pentaho インスタンスにアクセスすることさえできません。そして、Stackoverflow コミュニティの善良な人々が専門知識を共有してくれることを願っています。これをインストールする必要がなくなり、これを理解するために何時間もプレイ/テストする必要がなくなります。これは悪い考えです。

編集:

この質問が少し漠然としていることは知っていましたが、誰かがそれを読んで、経験を共有してくれることを望んでいました. ですから、より明確に説明し、より明確な質問をさせてください。

私は何もやっていません。ペンタホは知りません。私は Pentaho を学びたくありません (Pentaho に何か問題があるというわけではありません... ただ、私の関心が今のところそこにあるわけではありません)。私の会社は請負業者を雇いました(私は彼らを雇いませんでした)。彼らは Pentaho の経験がありますが、MySQL の経験があります。彼らは PostgreSQL について何も知りません。PostgreSQL と MySQL の間にはいくつかの重要な違いがあります。PostgreSQL がスキーマをサポートしているという事実を含めます (一方、MySQL は別のデータベースを使用します... 概念は似ていますが、いくつかの点で動作が異なります)。一部の ORM (およびツール) は、これがあまり好きではありません... たとえば、Djangoフレームワークは、Postgresql のスキーマをまだ完全にはサポートしていません (私は Python と Django を頻繁に使用しており、物事を「パブリック」スキーマに保持すると、私の生活ははるかに良くなるため、これを知っています)。Django と PostgreSQL スキーマの経験があるため、このデータを新しいスキーマに移行することに少し不安があります。

テーブルがどこにあっても、データにアクセスできる権限が必要であることは理解しています。

私の明確な質問:

  • Pentaho を使用して PostgreSQL データベースにアクセスし、"public" (デフォルト) 以外のスキーマのテーブルにアクセスしますか?
  • もしそうなら、それはうまくいきますか(問題ありません)?
  • 問題が発生した場合は、私 (および Stackoverflow コミュニティ) に役立つオンライン リソースを共有していただけませんか? または、ここで覚えていることを詳しく説明していただけますか?
  • 正しく動作しないものを知っていますか? たとえば、このトピックに関連する Pentaho の未解決のバグです。

繰り返しますが、それはあなたの標準的な種類の質問ではありません。私は誰かが経験を持っていて、それをここで喜んで共有し、新しい Pentaho インスタンスをセットアップして、それをテストするのに十分なほど十分に Pentaho を学ぼうとするのに時間を費やす必要がないことを望んでいます.

ありがとう。

4

4 に答える 4

2

あなたが取ることができる2つの道:

1)以前の投稿で述べたこと(「Pentahoの手順(テーブルの入力、出力など)では、通常、データベーススキーマを指定できます。」)

2)データベース接続で、[詳細設定]タブの[優先スキーマ名]。

異なるスキーマを使用している場合は、スキーマごとに1つのデータベース接続を作成できます。このアプローチでは、入出力ステップのスキーマフィールドを空のままにすることができます。

于 2012-10-30T11:20:05.563 に答える
2

私は PDI と PgSQL を毎日、さまざまなスキーマで幅広く使用しています。それは正常に動作します。遭遇する可能性のある唯一の問題は、引用符で囲まれていない識別子を大文字ではなく小文字にするという Pg の厄介な慣行です。詳細接続プロパティを「データベース内のすべてを引用」に設定すると、すべてが簡単になることにすぐに気付きました。

はい、PDI がそれを行わない場合、SQL を入力するときにすべてを引用する必要がありますが、それは非常にうまく機能します。すべての識別子を小文字に強制する実験はしていませんが、それもうまくいくと思います。

はい、「Preferred schema nanme」も使用しますが、一部のステップではそのオプションを使用し、他のステップでは使用しないことに注意してください。たとえば、テーブル入力ステップに入力する SQL にスキーマ名を追加することは期待できません。

他に遭遇する可能性がある唯一の問題は、Pg の JDBC ドライバーの制限です。これは SQL Server や DB2 ほどではありませんが、テーブル出力ステップがバッチ モードのときに、エラー行をテーブル出力ステップから別のステップに送信することだけが問題でした。

楽しみながらPDIを学びましょう。これは、DBA スキルを補完するのに最適です。

ブライアン

于 2012-12-21T23:36:44.000 に答える
2

私たちは MS SQL サーバーを使用していますが、Pentaho はスキーマの考え方に苦労していると言えます。彼らのアプリの多くはスキーマを選択できますが、Pentaho は、あなたが言ったように、mySQL のようなものを使用するように構築されています。

pentaho データベース ユーザーが mySQL で動作するように動作するようにします。

データベース ユーザーのデフォルトを dbo に設定し、dbo.dimDimension、dbo.factFactTable などのテーブルを構造化しました。基本的に、dbo は Pentaho の目的でのみ使用します。(または、デフォルトにしたい任意のスキーマ。)

于 2012-11-06T23:19:30.370 に答える
1

通常、Pentaho の手順 (テーブルの入力、出力など) では、データベース スキーマを指定できます。

PDI と 8.4 Postgres インスタンスを使用して簡単なテストを行ったところ、さまざまなスキーマのテーブルを探索、読み取り、書き込みすることができました。

ですから、これは合理的な方向性だと思います。お役に立てれば。

于 2012-10-22T20:05:42.240 に答える