2012-09-02 36 views
0

可能重复:
Mongodb database Schema Design with shared data的MongoDB数据库架构设计技巧

您好我是新手,我mongodb.I使用Java。

我在我的关系表中有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。

在授权表,SYSTEM_ID是指系统TABEL 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的收藏?

我需要嵌入r使用dbref吗?帮助我为此设计模式。

回答

1

从您提供的架构信息,它看起来像你(通过JOIN表System_prop)租户和系统之间的许多一对多的关系,以及系统与授权之间的一个一对多的关系。

在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,但不向Tenant表请求任何信息。第二个从授权表请求Prop_Info,但该表没有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

最后,这取决于你的应用程序和最频繁的查询究竟如何你选择存储数据,上面的例子只是设置模式的一种方法。

+0

是的,我已编辑查询now.kindly,看看。 – Ramya

1

您仍然在关系数据库中思考。然而,MongoDB是一个面向文档的数据库。

  1. 人工ID号码通常是不需要的,因为每个文件自动有一个_id字段,这是一个GUID(保证是全局唯一的)。
  2. 关系表不应该在MongoDB中使用。 n型关系是用数组字段替代的。所以当1个系统有N个授权使用时,你的系统文件应该有一个字段“授权”,它是它拥有授权的对象ID的数组。是的,那将违背关系数据库的规范化规则。但是这里没有关系数据库。在MongoDB中,用数组表示N关系是可行的,因为数组对查询语言是透明的。