组织/位置/部门/用户的最佳DB结构？

我建立的，我们应该有一个包含组织，地方，部门和用户数据库的系统。它们连接你所期望的：组织/位置/部门/用户的最佳DB结构？

每个组织可以包含一个或多个位置
每个位置（建筑）可包含在各部门工作的一个或多个部门
一个或多个用户
一个用户可以在多个部门工作

但是：部门可以跨越多个位置。

直观上我会创建DB如下：上面看到的结构的问题是BUT;不可能有一个跨越两个地点的部门。我认为这不是一个真正的问题，因为我可以简单地为两个位置创建相同的部门。如果有这个部门的管理员，我可以简单地让他在这两个地点的管理员。

一个程序员提出了不同的结构，但：

他是这个结构的大风扇，因为他说，这是方式更加灵活，跨越东西翻过什么。我的问题是手动读取数据库时可读性差，另外在编写代码时我会更加困惑。

我的问题是;你更喜欢哪种结构？这最后一个结构的优点是什么？这是更经常使用吗？欢迎所有提示！

来源

2016-12-01 kramer65

那么，我读的是你有一个结构，它的工作原理，但可能会有点难以阅读，和一个不工作，你问哪一个我们更喜欢...查看与工作 – SaggingRufus

@SaggingRufus的一个 - 好了，第一个是在我看来，这样更具可读性，它有一个缺点在我看来是不是真的在实践中的问题，而另外一个可能迎合为所有可能性，但使事情变得非常复杂。我的问题是;是第二个数据库设计使用了很多，还是这种程序员的一种模糊的想法？ – kramer65

@ kramer65我从来没有见过第二个设计。也许这是因为（如果黄色键是主键那么它甚至不是以正常形式）（外键太多f.ex.）。 – pozs

假设：企业有多个部门，各部门都有多个位置，用户在该部门的地点之一为一个部门工作。

这里是我的速写：

CREATE TABLE Users 
(user_id INTEGER NOT NULL UNIQUE); 

CREATE TABLE Organizations 
(org_id INTEGER NOT NULL UNIQUE); 

CREATE TABLE Departments 
(dep_id INTEGER NOT NULL UNIQUE); 

CREATE TABLE Locations 
(loc_id INTEGER NOT NULL UNIQUE); 

CREATE TABLE OrgDepartments 
(org_id INTEGER NOT NULL UNIQUE 
    REFERENCES Organizations (org_id), 
    dep_id INTEGER NOT NULL UNIQUE 
    REFERENCES Departments (dep_id)); 

CREATE TABLE DepartmentLocations 
(dep_id INTEGER NOT NULL UNIQUE 
    REFERENCES OrgDepartments(dep_id), 
    loc_id INTEGER NOT NULL 
    REFERENCES Locations (loc_id), 
    UNIQUE (loc_id, dep_id)); 

CREATE TABLE UserLocations 
(user_id INTEGER NOT NULL UNIQUE 
    REFERENCES Users (user_id), 
    dep_id INTEGER NOT NULL, 
    loc_id INTEGER NOT NULL, 
    FOREIGN KEY (loc_id, dep_id) 
    REFERENCES DepartmentLocations (loc_id, dep_id));

来源

2016-12-01 16:49:43 onedaywhen

看起来很不错。如果用户在一个以上的位置工作，用户只需在UserLocations表中获取多个记录？ – kramer65

@ kramer65是的，但您需要更改密钥以适应此情况。 '（dep_id，user_id）' – onedaywhen

组织/位置/部门/用户的最佳DB结构？

回答

相关问题