Sql 按层分配的数据库表结构

我有一个四层账户结构（从上到下）：

师级

部门级

销售代表级别

帐户级别

业务用户需要能够在四个级别中的任意一个级别分配/分配产品单元。在师级分配100个单位可以让任何更深层次的单位从这个平衡中获益。将100个单位分配给销售代表级别只允许他/她的帐户从该余额中提取

我知道如何在4表结构中对此进行建模，但这是正确的方法吗？是否所有四个级别的记录都应存储在同一个表中，并有一列指示在哪个级别分配单元

如果我将它们都放在同一个表中，我如何说明部门、部门、销售代表和帐户代码是四个不同表中四种不同类型代码的问题。我需要每行四个FK

编辑

为了清楚起见，我加入了一张图片，我认为这是我的两个选择。选项1导致某些列的值为空。选择2是更好的选择吗？这是一个事务数据库，而不是数据仓库

（将此作为答案，因为评论部分的大小太有限。）

在国际海事组织，这两种解决方案都不是很有前途的。如果在层次结构中添加了一个新级别，该怎么办？您必须为选项1添加一个新列，或为选项2添加一个新表，然后更改所有视图/查询。在这两种情况下，你将如何跟踪哪个层次结构的优先级高于应用程序中硬编码的其他层次结构？此外，您似乎只跟踪在任何时间点分配的总单位，而不是池中潜在单位的总数（我想这就是DMason的问题的目的）？而且，您似乎假设一次只能在一个层级分配所有潜在池：如果您的公司希望将灵活性分配给每个层级（例如，部门500个，帐户500个），该怎么办？因此，我认为，从这些观点来看，您目前提出的建模选项是不灵活的

首先制作一个层次表不是更有意义吗？您将有一个HierarchyLevelID（identity）列，然后是每个级别（目前为部门、部门、销售代表和帐户）的描述列，每个级别都有一个优先级，例如1.0-4.0。也可能是一列，您可以存储该级别引用其引用数据（部门、部门等）的表的名称。也许这甚至可能是相关表的内部对象ID。然后可能是一个具有HierarchyLevelID、ExternalID（DivisionID、DepartmentID等，以与HierarchyLevel相关的为准）、AssignedAllocationUnits（用于该级别）、CurrentlyAllocatedUnits（也用于该级别）的分配表。如果有一个包罗万象的数据元素来绑定分配，比如ProjectID，那么您也应该包括它（如果您在层次结构级别中也有这个元素，那么不同的项目甚至可以获得不同的层次结构级别和优先级！）。甚至可能是一个计算列，TotalAllocationUnitsAvailable，它执行繁重的操作，并计算该级别（不仅仅是显式分配的）的总可用单位-但是，这可以很容易地卸载到视图中。我认为这就是您需要的所有持久存储

此模型中的一个挑战是确保Allocations.ExternalID反映它所引用的基表中所做的更改。您不能在这里执行FK解决方案，因为这一列包含许多不同表的键。这可以通过基表本身的触发器逻辑来实现（我意识到这很可能是轻描淡写的，lol）。然后，另一个挑战是计算在任何给定时间任何给定级别的TotalAllocationUnitsAvailable以及事务处理，如果多个级别试图同时声明AllocationUnits，则需要这些事务处理来确保所有内容都符合洁净度。这些问题需要仔细考虑和实施

---

话虽如此，我相信提出的解决方案将解决我早些时候提到的问题，并允许在数据方面而不是对象方面进行更改，从而实现更大的灵活性。这显然是一个速写，但我想你知道我要去哪里。至少，请至少考虑一下我对你们目前的建议提出的挑战。看起来是个有趣的项目，祝你好运

在四个表中的每个表中添加一个

AllocatedUnits

列是否更有意义？否。这四个表是每个级别的维度。例如，DivisionId、DivisionName。。。。。或SalesRepId，SalesRepName。。。。等等如果我将分配放在一个表中，我会在一些外键中有空值。也许我们彼此误解了。我指的是向每个“结构”表添加

AllocatedUnits

。例如，

创建表部门（部门ID、部门名称、分配单位…

和

创建表部门（部门ID、部门名称、分配单位…

等）。如果只有一种分配单位，这是有意义的。如果有多种分配类型，那么我的建议将不适用。有多种类型的项目等等。然而，如果我这样做的话，听起来就像我的图表中的选项2。是的，我倾向于同意选项2。我想你会为

AllocationType

添加一个专栏吧？我同意这两个都不是很有前途的，这就是我在这里发布的原因。然而，这种结构在公司已经存在了20多年。并不是说它不能改变，但肯定是非常静态的。我确实有你所说的结构（为了简洁起见，请不要提及），但我认为你提到了我所害怕的东西。我需要复杂的逻辑来动态引用