1

私が取り組んでいるシステムは、次のように構成されています。私はJoomlaをベースとして使用する予定です。

ここに画像の説明を入力

a(www.a.com)、b(www.b.com)、c(www.c.com) は、ユーザーが予約を検索できる検索ポータルです。

x(www.x.com)、y(www.y.com)、z(www.z.com) は、ユーザーが予約するホテルです。

  • www.a.com のユーザーは、www.x.com にある予約のみを検索できます。
  • www.b.com のユーザーは、www.x.com、www.y.com にある予約のみを検索できます。
  • www.c.com のユーザーは、www.x.com、www.y.com、www.z.com にあるすべての予約を検索できます。

すべての a、b、c、x、y、z は同じシステムを実行します。ただし、ドメインは別々にする必要があります。したがって、私の発見と研究によると、アーキテクチャは上記のようになり、API がすべてのデータベース呼び出しを統合する必要があります。

ここでは 6 つのインスタンス (a、b、c、x、y、z) のみが示されています。さまざまな検索の組み合わせで、最大 100 個まで可能です。

私の問題、

システム全体で単一のデータベースを維持する必要がありますか? その場合、必要に応じて 1 つのインスタンスを取り外すにはどうすればよいですか (例: システムから www.a.com を削除するか、システムから www.z.com を削除します)? mysql を使っているので、レコード数が多くてシステムが煩わしくありませんか?

インスタンスごとに別々のデータベースを維持している場合、どうすれば検索できますか? 必要なレコードを 1 つに統合して検索するにはどうすればよいですか?

上記以外に使用する別のデータベース アプローチはありますか?

4

2 に答える 2

2

あなたが説明する問題は「マルチテナンシー」です。解決するのはかなり難しい問題ですが、幸いなことに、他の人がいくつかの有用なアプローチを書いています。(リンクは Microsoft へのものですが、詳細を除いて、ほとんどの SQL 環境に適用されます)。

あなたの場合のトレードオフは次のとおりです。

  • ホテルのデータは単一のスキーマに収まりますか? 「欠員」レコードには同じフィールドがありますか?
  • ホテルは何軒になりますか？3つの別々のデータベースはちょっと扱いやすいです。30 はおそらくそうではありません。300は絶対にありません。
  • データベースはどのくらい大きくなりますか? 欠員の記録はいくつですか？
  • データ構造が時間の経過とともに変化する可能性はどのくらいありますか? あるホテルでは変更が必要で、他のホテルでは必要ない可能性はどのくらいありますか?

管理と開発が最も簡単なのは「単一データベース」モデルですが、これは、データがスキーマで適度に均一であり、妥当なパフォーマンスでデータをクエリできる場合に限られます。MySQL に多くのレコードを入れることについて心配する必要はありません。非常にうまくスケーリングします。

このような設計では、ルックアップ テーブルで「ポータル」を「ホテル」にマップします。

ポータルホテルアクセス

PortalID   HotelID
-----------------
A          X
B          X
B          Y
C          X
C          Y
C          Z
于 2012-11-27T10:57:23.507 に答える
1

2つのアプローチを提案できます。どちらを選択するかは、システム全体に関する追加情報によって異なります。実際、主な問題は、システムが消費者の観点 (a、b、c など) からデータプロバイダー (x、y、z など) のいずれかになりすます (法的な意味でそれ自体で代用する) ことができるかどうかです。 .

集中型データベース

最初のものは、実際には集中型 API を使用した元のスキームに基づいています。データ ソースから必要なデータを収集し、それを独自の DB に集約し、データの消費者に提供する単一の検索エンジンを意味します。

これは、データ ソースのデータ表現が異なる場合に最適なソリューションである可能性が高いため、均一性のために前処理する必要があります。また、このバリアントは、接続の潜在的な問題からクライアントを保護します。つまり、ソース サイトの 1 つが短期間オフラインになった場合 (これは、予約サービスの現実に大きな影響を与えることなく、最大で数時間かかる可能性があると思います)、それでもできます。オフライン サイトへのリクエストを処理し、問題が解決するまですべての新しいドキュメントを中央 DB に保存します。一方、これは、DB とすべてのデータ ソース サイトとの間である種の双方向同期を提供する必要があることを意味します。また、集中型の DB はそもそも信頼性を考慮して作成する必要があるため、分散 (できれば異なるデータ センターに分散) する必要があるようです。

結果として、このアプローチはおそらく最高のユーザー エクスペリエンスを提供しますが、堅牢な実装には十分な努力が必要です。

複数のローカル DB

すべてのデータ プロバイダーが独自の DB を実行しているが、それらすべて (バックエンド API を含む) が単一の標準に基づいている場合、それらのデータを中央の DB にコピーする必要がなくなります。もちろん、中心点は残す必要がありますが、DB なしで中間層のロジックのみをホストします。レイヤーは実際には (x, y, z) を適切な (a, b, c) にバインドする API です。これは構成であり、それ以上のものではありません。すべての消費者サイトは、適切な設定が埋め込まれた中央ポイントから読み込まれたウィジェット (単なる JavaScript または本格的な Web アプリケーション) をホストします。

ウィジェットは、指定されたすべてのバックエンドを直接リクエストし、それらの結果を 1 つのリストに集約します。

このバリアントは、今日のほとんどの Web アプリケーションの動作によく似ており、実装が簡単ですが、エラーが発生しやすくなっています。

于 2012-11-27T10:41:49.487 に答える