数据库设计问题

我有涉及实体的多对多关系：部门和范围。数据库设计问题

1）部门。（进口，出口）
2）范围。（Nationwide，International）

1部门可以与许多不同的范围相关。一个范围涉及多个部门。

到目前为止，我的多对多的关系表会是这样的：

DepartmentID的（外键）
ScopeId。（外键）

每个部门/范围的关系将有一个整体的配置，包括文件类型和批号等

（所以对：

部门1/1的范围/文档类型1
部门1 /范围1 /文档类型2

然后为每个文档类型会有一些不同的代码：

部门1 /范围1 /文档类型1/COD ë1
部门1 /范围1 /文档类型1 /码2

部门1 /范围1 /文档类型2 /代码1
部门1 /范围1 /文档类型2 /码2

所以我在具有多对多的关系表（部/范围）思想为：

ID（自动增加）（主键）
DepartmentID的
ScopeId。

这个“Id”将是另一个表中的外键。

这样好吗我在做什么或者我是否违反了一些最佳实践规则？

感谢

更新1
我发现，我将有许多不同的多对多关系的表。

1）定义范围相关的各部门

标识
DepartmentID的
ScopeId涉及每个部门内的每个范围

2）文件类型。

ID（主键，autoincrementable）
DepartmentScopeId（外键，1）
DocumentTypeId（外键，文档类型）。

3）与每个文档类型相关的代码，属于某个部门的范围。

Id（主键，自动增量）。
CodeName（nvarchar（50））
DocumentTypeDepartmentScopeId（外键为2））。

我不太确定如果我是过于复杂的事情，或者如果这是数据库世界中的正常模式。

我这样做后，我想我能创建一个视图，这将帮助我在访问数据，例如：返回所有代码，每个文件类型，每个范围，每部”如果我能

将是巨大的关于这是否会是去了解这个正确的方式获得一些建议。

感谢

来源

2011-03-20 rauland

“数据库设计”并不意味着“在每张桌子上放置一个自动增量的ID号码”。如果你这样做，你几乎可以肯定不会执行* real *限制。例如，在部门范围的表中，必须声明一对列{departmentid，scopeid}为“PRIMARY KEY”或“UNIQUE”。 – 2011-03-20 13:16:10

我也觉得这是最好的做法。您也可以在新表中添加有关关系的详细信息（例如dateCreated会，如果这是有道理的）。另外，如果它很重要，不要忘记将这对夫妇（DeparmentId，ScopeId）设置为独特以避免重复分配。

来源

2011-03-20 10:33:15

数据库设计问题

回答

相关问题