我对这个设计问题感到很难过，并且非常感谢任何见解。
我有一个医生办公室，提供某些特权，目前只有5个特权，但可以添加更多特权。这些权限中的每一个都具有“是”或“否”的状态，但将来可能会有更细粒度的状态，并且这些权限中的每一个都与位置（呃，住院病人，门诊病人）相关，并且它们以后也可以扩展。
所以目前我有表OfficePrivileges，PrivilegeLocation，PrivilegeType，PrivilegeStatus。
OfficePrivilege是PrivilegeLocation和DoctorOffice之间的连接表。它有一个OfficeID和PrivilegeLocationID的双主键。
有一段时间，我将Type和status加入了OfficePrivileges Table，然后切换为将type表格作为Location的子级，状态为type的子级。它们都是单个主键表。
如果你正在设计这组表格，你会怎么做？我认为这几乎是一个层次结构问题......我讨厌它们。我想将编辑屏幕布局为交叉表，顶部有位置，键入侧面，详细信息是状态。这就是我目前在我试图集成的系统中的方式，但它是一个Cobol后端并且比关系数据库更好地处理层次结构....
编辑：帮助消除混淆：
我的例子有Admit Privileges，Attending Privileges，Consulting privileges和Surgery Privilges。并且位置是住院病人，急诊室，门诊病人和OP /手术。目前状态仅为是或否。但是根据客户的需要，它们将来可能会发生变化。
此信息存储在我的数据库中的表中。
答案 0 :(得分：0)
我觉得最重要的是尝试尽可能灵活，因为你知道“可能的”变化，但你真的不想为那些代码编写代码。
你所拥有的东西可能非常好：我会这样：你实际上在办公室，PrivilegeLocations和PrivilegeTypes之间有三向关系
我想说你的OfficePrivaleges表应该包含以下6列：Id (its own PK), OfficeId, LocationId, PTypeId, StartDate, EndDate当为Office授予新的权限时，您将向此表添加一条记录，将三者连接起来并添加第一个日期。拥有StartDate的特权。如果撤消权限，请将该日期添加到EndDate。如果它已重命名，请添加新行，或重置StartDate。
我会避免使PrivilegeType成为PrivilegeLocation的子项，因为那时您必须存储每个位置n次（n =不同的权限组合）。这样，您每次只能存储办公室，位置和类型。
因此，例如，医生A可能在位置X具有住院患者权限，但在位置Y只有DX成像权限，而医生B可以在位置X和Y具有住院患者权限。