我正在尝试设计一个数据库来存储主管的承诺。该界面将通过网络浏览器。
我遇到的问题是每个主管在其电子表格中当前跟踪的字段不同。这是因为每个主管的小组执行不同类型的工作（承诺）。
我是否应该有一个包含所有字段的承诺表，并随着越来越多的主管使用它并请求他们的字段而继续添加新的承诺表？
或者我应该考虑承诺项目描述的内容吗？而是有一个通用的承诺表，然后为每种类型的承诺提供表来存储唯一字段并使用 JOINS？这些额外的表格可能只有一两个字段。
第三种选择可能是只为每种类型的承诺设置单独的表，并在每个表中重复所有公共字段（开始日期、结束日期、描述）。
【问题讨论】：
标签： database-design
这取决于：如果承诺是动态的，这意味着主管可以发明新的承诺，那么我会选择一个包含所有不同承诺的承诺类型表：
Table CommitmentType(Id, Description, ...)
Table SupervisorCommitment(Id, CommitmentTypeId, SuperVisorId, StartDate, EndDate, ...)
这样，主管可以添加新的承诺类型，但也可以共享它们。
更新：如果承诺也有不同的字段，那么更规范化的设计版本将是还有一个描述字段的 Field 表和一个 CommitmentType 到字段的关系表（以防万一它是 m:n) 或字段表中的承诺类型 ID，以防您不想在承诺之间共享字段。像这样：
Table Field(Id, Name, TypeDescription, CommitmentTypeId)
或
Table Field(Id, Name, TypeDescription)
Table CommitmentTypeFields(FieldId, CommitmentTypeId)
这样您就可以为每个承诺创建新承诺和新字段。
您还可以考虑使用像 MongoDb 或 Cassandra 这样的面向文档的数据库，它们在数据存储方式上具有更灵活的方法。但是，它们还有其他缺点，您应该在跳上“NoSQL”大车之前调查并仔细权衡。
更新 2：然后可以像这样将值存储到 CommitmentFieldValue 表中：
Table CommitmentFieldValue(CommitmentTypeId, FieldId, Value)
另外：仅仅因为您在数据库设计中具有创建新承诺类型和字段的灵活性并不意味着您必须将其公开给 UI。
【讨论】：
听起来您的方案中的承诺主要是半结构化/非结构化数据。您是否考虑过将它们存储为 XML 或使用与关系数据库一起运行的原生 XML 数据库？
eXist 是一个很好的原生 XML 数据库，带有 REST API，可让您轻松查询承诺并在 Web 浏览器中显示。
【讨论】：
我的想法是有一个通用的“承诺”表，其中包含所有常见数据和一个承诺类型字段。优点是当您显示列表时，您可能不需要加入明细表。
当您在寻找细节时，您可以加入正确的表格。甚至可以做一些灵活的事情，比如在键/值表中包含详细信息。详细信息字段的类型和值都存储在其中，因此添加新字段非常容易。
【讨论】：
基本问题是“我如何使用数据库来存储多态数据？”；到目前为止，您已经获得了我所知道的所有可用答案：
要选择正确的解决方案，我建议考虑您的设计可能必须支持的查询类型，并确定如何在每个可用模型中编写这些查询。
我猜您可能需要诸如“查找所有逾期承诺的主管”、“按类型查找所有逾期承诺”、“查找没有承诺的主管”、“我们在整个企业中有多少承诺、分组按类型？”。想想你会如何回答它们——也许在开发盒上模拟一些东西。
最终，您将不得不考虑权衡 - 未来的灵活性与今天的开发轻松/速度。
【讨论】：