我有一个四层帐户结构(从上到下):
业务用户需要能够在四个级别中的任何一个级别分配/分配产品单元。在分部级别分配100个单位允许从该余额中获取任何更深层次。将100个单位分配给销售代表级别只允许他/她的帐户从该余额中获取。
我理解如何在4表结构中对此进行建模,但这是正确的方法吗?是否应将所有四个级别的记录存储在同一个表中,并使用一列指示单位的分配级别?
如果我将它们全部放在同一个表中,我如何解释分部,部门,销售代表和帐户代码是四个不同表中4种不同类型代码的问题。我每行需要四个FK?
修改
为了清楚起见,我提供了一个图像,我认为,这是我的两个选择。选项1导致某些列的NULL值。选项2是更好的选择吗?这是一个事务数据库,而不是数据仓库。
答案 0 :(得分:1)
(将此作为答案,因为“评论”部分的尺寸限制太大。)
IMO,这两种解决方案都不具备前瞻性。如果添加了层次结构中的新级别,该怎么办?您必须为选项1添加新列,或为选项2添加新表,然后更改所有视图/查询。在任何一种情况下,您将如何跟踪层次结构的哪个级别优先于另一个级别 - 在您的应用程序中进行硬编码?此外,您似乎只跟踪在任何时间点分配的总单位,而不是跟踪池中的潜在单位总数(我认为这是DMason的问题所得到的)?而且您似乎假设总潜在池一次只分配在一个层级:如果您的公司希望灵活性分配给每个级别(例如,500为分部和500在帐户级别),该怎么办?所以我认为到目前为止你所提出的建模选项从这些观点来看是不灵活的。
首先制作HierarchyLevels表会不会更有意义?您将拥有HierarchyLevelID(标识)列,然后是每个级别的描述列(分部,部门,销售代表和帐户,现在),每个级别将获得优先级,例如1.0-4.0。也许还有一个列,您可以存储表的名称,该级别引用其参考数据(部门,部门等)。也许这甚至可能是相关表的内部OBJECT_ID。然后可能是一个Allocations表,它具有HierarchyLevelID,ExternalID(DivisionID,DepartmentID等,与HierarchyLevel相关),AssignedAllocationUnits(用于该级别),CurrentlyAllocatedUnits(也用于级别)。如果有一个绑定Allocations的总体数据元素,比如ProjectID,那么你也可以包括它(如果你在HierarchyLevels中也有这个,那么不同的项目可以获得不同的层次结构级别和优先级,甚至!)。甚至可能是一个计算列,TotalAllocationUnitsAvailable执行繁重的工作并计算该级别的总计可用单位(不仅仅是明确指定的单位) - 但这可以很容易地卸载到视图中。我认为这是您需要的所有持久存储。
此模型中的一个挑战是确保Allocations.ExternalID反映它引用的基表中所做的更改。你不能在这里做一个FK解决方案,因为那一列保存了许多不同表的密钥。这可以通过基表本身的触发逻辑来完成(我意识到很可能的轻描淡写,哈哈。)。然后另一个挑战是在任何给定时间为任何给定级别计算TotalAllocationUnitsAvailable以及如果多个级别试图同时声明AllocationUnits则确保一切都是犹太的所需的事务处理。这些问题需要仔细思考并实施。
话虽如此,我相信所提出的解决方案将解决我早期提到的问题,并允许通过允许在数据方而不是对象方面进行更改来实现更大的灵活性。这显然是一个快速草图,但我想你知道我要去哪里。至少,请至少考虑一下我提出的有关您当前建议的挑战。看起来像一个有趣的项目,祝你好运。 =)