帮助“灵活”与固定表

Question

我们正在 SQL Server 中设计一个数据库来处理销售佣金。当前模式的图表如下所示：

这个项目只有我们几个人，我们的老板把这个设计交给了我们。我是一个新手，但我很担心这个Slot表，因为我们似乎正在朝着 EAV 模型前进，而且我认为我们的团队没有足够的经验来克服这些陷阱。

ASlot可以是公司、地点、地区、路线或位置（基于其SlotType）。我们有这些实体的表格，但管理层希望“灵活”地为彼此分配插槽 ( SlotHierarchy)。我不会陷入适用于每个槽位、槽位类型、槽位级别、槽位级别类型和员工职位分配的混乱的生效日期。所有生效日期都是因为管理层想要控制每一件作品。

计划是将Employeeget 分配到位置槽 ( SlotPositionAssignment)，然后可以将其分配到位置、路线或区域槽。一个职位在给定时间只能分配一名员工。不过，一个位置可以分配给任意数量的插槽。

因此，我们可能有PositionType“销售员”和SlotDesc“销售 1”和“销售 2”两个职位（插槽），每个职位都分配了一名员工。这两个职位可以分配到多个路线、地区、地点或公司时段。这SlotHierarchy有助于解决这个问题。

我的担忧：
恐怕我们可能会因此而自诩。我不介意编写额外的应用程序逻辑，但这似乎“太聪明了”。直言不讳并使用映射到现实生活中的表格而不是将它们隐藏为“插槽”不是更有意义吗？

我想取消将职位作为插槽并使用Position表格，或者可能只是PositionType在我们失去报告公司特定职位的能力时使用，例如“Rt 1 Manager”。当我提出这个问题时，我被告知它不会“灵活”，这就是它的结束。

有没有更好的方法来组织这个，或者做出一些妥协，或者我什么都不担心？我是新手，不介意犯错，只要我知道为什么我错了。

Answer 1

我建议您考虑一下该系统的用例。在你自己的头脑中计算出查询将如何寻找给定的设计和你的替代方案。包括人们在时段之间移动的场景。更新是什么样的？可以在 DRI 中强制实施业务约束吗？还能找到所需的值吗？通过实际的例子来讨论将突出你的担忧，并让你的老板更全面地解释模型。

针对可怕的模式编写可怕的查询只是问题的一部分。当它们损坏时，必须有人在凌晨 3 点在没有文档的情况下修复它们。在此阶段更容易理解的查询将为您更快地提供更好的系统。

如果这能让你安心的话，我已经在 EAV 系统上取得了成功。也就是说，我们是一个由非常有经验的 DBA 组成的团队，这确实是一个蓝天、“假设”项目，不，我们并没有把公司的赌注押在它上面。我们强烈反对任何将要投入生产的开发项目使用 EAV 方法。

如果您走“灵活”路线，请不要仅仅因为您有通用模式而尝试编写通用查询。每个查询应该只处理公司、位置、地区或您的插槽类型之一。

我的两分钱的价值。