0

重複の可能性:
共有データを使用した Mongodb データベース スキーマ設計

こんにちは、mongodb の初心者です。Java を使用しています。

リレーショナル テーブルに Tenant、system、authorization の 4 つのテーブルがあります。

このようなもの。

Table            Fields

 Tenant           Tenant_ID(PK), Tenant_INFO
 System           System_ID(PK), System_Info
 Authorization    System_ID, Autho_Info.
 System_prop      System_ID, Prop_Info, Tenant_ID

System_prop テーブルでは、Tenant_ID はテナント テーブル Tenant_ID (PK) を参照し、System_ID はシステム テーブル System_ID を参照します。

Authorization テーブルでは、System_ID は System テーブル System_ID を参照します。

データベースをリレーショナルから mongodb に切り替えています。最初に行う必要があるのは、スキーマの設計です。

私がする必要があるクエリは次のとおりです。

SELECT D.Prop_Info, D.System_ID, A.Tenant_Info From TENANT A ,System_prop D, SYSTEM B, Where D.System_ID = B.System_ID AND D.Tenant_ID = A.Tenant_ID

SELECT C.System_ID, C.auth_Info, B.System_ID FROM Authorization C, SYSTEM B WHERE C.System_ID = B.System_ID

これらのテーブルを mongodb のコレクションとして設計する方法を教えてもらえますか?

dbref を使用して埋め込む必要がありますか? このスキーマの設計を手伝ってください。

4

2 に答える 2

1

あなたはまだリレーショナル データベースについて考えています。ただし、MongoDB はドキュメント指向のデータベースです。

  1. 通常、人工的な ID 番号は必要ありません。すべてのドキュメントには、GUID である _id フィールドが自動的に含まれるためです (グローバルに一意であることが保証されています)。
  2. リレーション テーブルは MongoDB では使用しないでください。n 型の関係は、代わりに配列フィールドで作成されます。したがって、1 つのシステムが N 個の承認を使用する場合、システム ドキュメントには、そのシステムが持つ承認のオブジェクト ID の配列である「承認」フィールドが必要です。はい、それはリレーショナル データベースの正規化規則に対する恐ろしい違反です。しかし、ここにはリレーショナル データベースがありません。MongoDB では、配列はクエリ言語に対して透過的であるため、N 関係を配列で表すことが実用的です。
于 2012-09-02T23:00:56.530 に答える
1

あなたが提供したスキーマ情報から、(JOIN テーブル System_prop を介して) Tenant と System の間に多対多の関係があり、System と Authorization の間に 1 対多の関係があるようです。

MongoDB では、配列フィールドを使用してこれらのタイプの関係を両方とも実装できます。これは、システム コレクションをセットアップする方法です。

{
    System_Info: ...,

    Tenant: [ 
        { 
            Tenant_Id: ..., 
            Tenant_Info: ..., 
            Prop_Info: ...
        }, 
        { 
            Tenant_Id: ..., 
            Tenant_Info: ..., 
            Prop_Info: ...
        } ],

    Authorization: [ 
        {
            Auth_Id: ..., 
            Auth_Info: ...
        }, 
        {
            Auth_Id: ..., 
            Auth_Info: ...
        } ]
}

ただし、テナント情報については、非正規化された重複情報があります。つまり、同じテナント ドキュメントが異なるシステム ドキュメントに表示されます。一貫性を確保するのはアプリケーション次第です。

あなたが言及したクエリについては、いくつかの情報が不足しているようです。最初のクエリでは、テナント テーブルに参加していますがTenant_Id、テナント テーブルからの情報は要求していません。2 番目のリクエストProp_Infoは Authorization テーブルからのものですが、そのテーブルには がありませんProp_Info。A.Autho_Info代わりにそうすべきですか？したがって、これらのクエリを再確認することをお勧めします。

以下に、MongoDB のスキーマ設計に関する参考資料をいくつか示します。

http://www.mongodb.org/display/DOCS/Schema+Design

https://openshift.redhat.com/community/blogs/designing-mongodb-schemas-with-embedded-non-embedded-and-bucket-structures

最終的に、どのように正確にデータを格納するかは、アプリケーションと最も頻繁なクエリに依存します。上記の例は、スキーマを設定する 1 つの方法にすぎません。

于 2012-09-03T01:18:18.120 に答える