我正在尝试设计一个数据库来存储主管的承诺。界面将通过网络浏览器。
我遇到的问题是每个主管都有他们当前在电子表格中跟踪的不同字段。这是因为每个主管的小组执行不同类型的工作（承诺）。
我是否应该拥有一个包含所有字段的承诺表并继续处理新的字段，因为更多的主管使用它并请求他们的字段？
或者我应该考虑承诺项目描述的内容？而是有一个通用的承诺表，然后为每种类型的承诺存储表，以存储唯一的字段并使用JOINS？这些额外的表格可能只有一两个字段。
第三种选择可能只是为每种类型的承诺提供单独的表，并在每个表中重复所有公共字段（StartDate，EndDate，Description）。
答案 0 :(得分：1)
这取决于：如果承诺是动态的，意味着主管可以发明新的承诺，那么我会选择包含所有与此类似的不同承诺的承诺类型表：
Table CommitmentType(Id, Description, ...)
Table SupervisorCommitment(Id, CommitmentTypeId, SuperVisorId, StartDate, EndDate, ...)
这样主管可以添加新的承诺类型，但他们也可以共享它们。
更新：如果承诺也有不同的字段，那么设计的更规范化版本将是一个描述字段的Field表和一个CommitmentType到Fields关系表（如果你是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。
答案 1 :(得分：0)
听起来您的场景中的承诺大多是半结构化/非结构化数据。您是否考虑过将它们存储为XML，或者使用与关系数据库一起运行的本机XML数据库？
eXist是一个很好的原生XML数据库，带有REST API，可以让您轻松查询承诺并在Web浏览器中显示。
答案 2 :(得分：0)
我的想法是拥有一个通用的“承诺”表，其中包含所有常见数据和承诺类型字段。优点是当您显示列表时，您可能不需要加入详细信息表。
当您查找详细信息时，您可以加入正确的表格。甚至可以做一些灵活的事情，比如在键/值表中包含细节。在存储详细信息字段类型和值的位置时，可以非常轻松地添加新字段。
答案 3 :(得分：0)
基本问题是“如何使用数据库来存储多态数据？”;到目前为止，您已经掌握了我所知道的所有可用答案：
要选择正确的解决方案，我建议您考虑设计可能需要支持的查询类型，并确定如何在每个可用模型中编写这些查询。
我猜你可能需要查询，例如“查找所有过期承诺的主管”，“按类型查找所有逾期承诺”，“找不到承诺的主管”，“我们在整个业务中有多少承诺，分组按类型？“。想想你如何回答它们 - 也许在开发盒上模拟一些东西。
最终，您将不得不考虑权衡 - 未来的灵活性与当今的发展速度/速度。