2

マルチユーザー アプリケーションを作成する必要がある Play Framework を使用するプロジェクトに取り組んでいます。チームに特定のワークショップを追加する中央パネルがあります。これが最善の方法かどうかはわかりませんが、次のようなテーブルを生成したいです

team1_tablename team1_secondtable..

次に、仮想ホスト (例: http://teamawesome.workshop.com ) を使用して特定のリクエストがヒットすると、その特定のテーブルへのクエリを操作する必要があります。

問題はテーブルの生成ではなく、モデルの操作です。すべてのワークショップには、同じ一般的なテーブルが用意されます。モデルではテーブルなどを記述する必要がありますが、これが教義を備えた PHP である場合は、ワークショップ team1 を作成した後にテンプレートを作成しますが、Java でそれらを生成したとしても、それらもコンパイルする必要があります。私はもっ​​と研究をしなければなりません。

私の質問は、ここで銃を飛ばして可能な解決策をあきらめる前に、よりHibernate指向です。ぜひ聞きたいです

NamedQueries を使用することを考えましたが、読み間違えたかどうかはわかりませんが、休止状態の本を読んで、クエリを実行して結果を汎用モデルに追加できることを読んだので、そのモデルを使用してすべての結果を保持しています...

不明な点がある場合は、お知らせください (これはマルチ データベースの質問ではなく、一意のプレフィックスを持つさまざまなテーブル セットを使用していることに注意してください)。

4

5 に答える 5

1

私は Hibernate と別の Web フレームワークに精通しています。これを処理する方法は次のとおりです。

1 つのチームのために、すべてのニーズに対応する 1 つのテーブル セットを作成します。それから私は：

  • DB2 を使用する: チームごとにスキーマを作成し、一連のテーブルを各スキーマにコピーします。

  • MySQL の使用: テーブルのセットをそれぞれにコピーするたびに、新しいデータベースを作成します。注: MySQL の「データベース」は、他のデータベースのスキーマに似ています。（要点を見逃すよりも、物事を単純化しすぎて申し訳ありません）

これで、接続ごとに個別の hibernate.cfg.xml ファイルをセットアップできるようになりました (これは正確には最良の方法ではありませんが、非常に簡単なので開始するのがおそらく最善の方法です)。schema/db を含む接続パラメータを指定できるようになりました。これで、エンティティテーブルが「チーム」と呼ばれ、接続されている場所で「チーム」テーブルを使用するとしましょう...

非常に迅速に開始するには、ユーザーがログオンしたときにセッションでユーザー オブジェクトを作成します。ユーザー オブジェクトには、ログインで使用される URL を解析することによって決定される正しい hibernate.cfg.xml ファイルから構築されたすべてのデータベース リクエストに使用される Hibernate SessionFactory があります。

上記が機能したら...対処すべき深刻な効率の問題がいくつかあります。ログオンしている各ユーザーが SessionFactory を作成しているということです...同時使用があまりない場合は問題にならないかもしれませんが、その時点で Spring を調べて、チームごとに接続プールを使用することをお勧めします。このように、チームごとに 1 つのセッション ファクトリがあり、ユーザーがサインインするときに主要なオブジェクトが作成されることはありません。

このソリューションの利点は、各テーブル セットが独自の世界に存在するため、新しいテーブル セットを簡単に作成できることです。すべてのチームとテーブルに 1 つのエンティティ クラスの製品ではなく、エンティティ クラスのセットは 1 つだけです。データベース スキーマは、チーム名と必要な制約を追加することで、複雑ではなくシンプルなままです。チームがデータの所有権とプライバシーを必要とする場合、データベースを別の場所に移動するのは比較的簡単です。

欠点は、チームのためにモデルを変更する必要がある場合、(teamName を外部キーとして使用して設定された単一のテーブルとは対照的に) チームごとに変更する必要があることです。

于 2010-12-09T01:23:31.947 に答える
1

チームごとに異なるテーブルを使用するという考えは (成功したアプリがそれを使用する可能性があるにもかかわらず) 正直かなり単純であり、メンテナンスを考慮すると深刻な落とし穴があります.新しいテーブルまたは単なるインデックス... テンプレートとして DML スクリプトを作成し、いくつかの (カスタム) ソフトウェアを使用してそれらをすべてのチームで実行する必要があります...

他の回答 (Quaternion と Octav) で述べたように、2 つの実行可能なオプションがあると思います。

  1. 「チーム」をデータ モデルに組み込む
  2. 異なるデータベース/スキーマにデータを分割する

最適なオプションを選択するには、「チーム」が実際にデータセットを分割できるものなのか、それともデータモデルに取り込みたいもう 1 つのエンティティなのかを判断する必要があります。

ここで「分割」の代わりに「分割」を使用していることにお気付きかもしれません。これは、後者の用語が一般的に DBA によって「シャーディング」と呼ばれるものを示すために使用されるためです。「分割」はより強い用語を意図しています。

分割は、次の場合にのみ有効です。

  • 異なるパーティション内のエンティティが相互に参照する必要はありません
  • 異なるパーティションのデータにアクセスするクエリは必要ありません(これは、レポートに使用されるクエリにも当てはまります)

お分かりかもしれませんが、この意味での分割はあまり魅力的ではありません (今は大丈夫かもしれませんが、新しい機能を追加したい場合はどうすればよいでしょうか?) ので、私のアドバイスは「チームはエンティティです。 "解決策。

また、データベース/スキーマのセットを維持することは、実際には単一の (おそらくもう少し複雑な) データベースを維持するよりも難しいことに注意してください... 繰り返しになりますが、運用システムにインデックスを追加するにはどのような手順を実行する必要があるかを考えてください...

単一データベース ソリューションの唯一の欠点は、(特定の顧客向けのカスタマイズが原因で) 複数のフロントエンドを持つことになった場合に明らかになります。共有データベースへの変更は、それを使用するすべてのアプリケーションに影響を与える可能性があるため、リスクを最小限に抑えるために、さまざまな Web アプリケーションへのアップグレードを調整します (ただし、ほとんどの場合、互換性を損なうことなくデータベースを変更できることに注意してください)。

于 2010-12-10T18:31:05.690 に答える
1

何の情報も得られず、闇雲に撃つだけというのは、やはり少しもどかしいものです。それにもかかわらず、私は仕事を始めたので、終わらせようとします。私はあなたが次の解決策であなたの仕事をすることができると思います:

を書いて、PlayPluginすべてのリクエストにチームをリクエストに追加してくださいargs。次に、独自のNamingStrategy. で、チームを読んでテーブル名に入れるNamingStrategyことができます。request.args追加方法に応じて、Team _ またはTeam . それはあなたの好みのソリューションか、スキーマのあるものになります。db-schema があると思われるので、このテーブルをそのまま使用し、移行しないのがおそらく最善の解決策です。

次回はリクエストをもっと抽象的にして、テーブルの数、エンティティのチーム、テーブルのレコード数 (最大、平均、最小) などの情報を提供できるようにしてください。あなたのテーブルモデルはどれくらい安定していますか? これらはすべて、議論を伴う明確な推奨事項を提供するのに役立つ質問です。

于 2010-12-11T08:54:22.603 に答える
1

テーブルのセットを 1 つだけ使用できますが、各テーブルの外部キーとして TEAM_ID のようなものを使用できますか。

TEAM_ID が主キーになる 1 つの TEAM テーブルが必要です。これはテーブルに移行され、外部キーの一部になります。

たとえば、HighScores のコレクションを持つ Player エンティティがある場合、DB の Player テーブルには TEAM_ID (Team テーブルからの外部キー) があり、HighScores テーブルには合成された外部キー (Player_id、Team_id) があります。プレイヤーテーブルから来ます..

つまり、結論として、データベースの物理的なパーティション分割ではなく、論理的なパーティション分割を提案しています (最初に検討したように)。

これが理にかなっていることを願っています。間違いなくもっと考える必要がありますが、面白いアイデアだと思うなら、もっと詳しく考えてみます.

于 2010-12-08T08:35:08.197 に答える
0

モジュール vhost を試すことができますが、あまりよく維持されていないようです。でも、チーム名をテーブル名に入れるという発想は本当におかしいと思います。Postgres と Oracle にはそのためのスキーマがあります。したがって、myTeam.myTable を使用します。しかし、その場合は、自分で永続化を行う必要があります。別のアプローチは別のデータベースになりますが、やはりプレイによるサポートは十分ではありません。私はこれを試してみます

  • 多くのチームを必要としない場合は、チームごとに個別のプレイ サーバーを実行します。
  • すべてのモデルのチーム テーブルへの参照を配置します。次に、hibernate-filters を使用するか、各クエリに追加パラメーターとして手動で追加できます。もちろん、これによりパフォーマンスが向上します。この問題は、Oracle パーティションで修正できます。
于 2010-12-05T19:21:31.530 に答える