我目前正在开发一个票务系统，允许我们的用户根据自己的需要提交门票。即，如果部门“A”正在提交票证，则他们可以具有某些类型的问题类别（例如“供应品”或“打印机”）以及与所选类别有关的细节。 我已经制定了部分数据库设计，我正在寻找一些反馈。我从来没有从头开始构建一个系统，所以我有点紧张。
这是我的数据库设计的草稿版本
问题表
Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate |
-----------------------------------------------------------------------------
EquipmentIssueDetails表
Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------
SupplyIssueDetails表
Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------
NetworkIssueDetails表
Id | IssueId | Supervisor | Details |
-------------------------------------------------------------
备注表
Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
提前致谢
答案 0 :(得分：3)
我会拆分您的问题表，因此问题和分配是分开的。另外，我会添加一个问题类型表，并向问题
添加一个IssueTypeId列标识， IssueTypeId， 由...制作， CREATEDATE， 状态， 所有者
标识， 名称
标识， IssueId， 分配给， AssignmentDate， 活性
如果以后需要，这将允许多个人被分配到问题。它还允许记录从一个问题中取消分配的人员的历史。问题类型条目如下：1：设备，2：供应，3：网络
有一些不同的问题类型可以管理，但是如果你有很多，用Ikke建议的键/值表方法替换“详细信息”表可能会更好。
答案 1 :(得分：2)
你的设计很棒。包含每种类型问题详细信息的单独表格正是正确的方法。
不要遵循那些认为你应该拥有键/值对的人的建议。这种方法使一些事情变得更容易，但当你尝试做其他事情时，它会迅速变成一场噩梦。您可以使用完整的RDBMS。使用它！
每个表格中的每一行代表一个关于世界的真实命题。数据库设计越能反映出您想要追踪的重要现实，那么您就越好。
如果将来需要跟踪更多详细信息，请添加更多列。如果结果是存在其他问题类型，则添加更多表。问题类型表不会添加任何内容。
在制定报告或对这些数据进行分析时，遵循这一原则将带来巨大的回报。
您应该考虑遵循OG的建议，允许每个问题允许多个受理人，或跟踪分配历史记录。这取决于系统的使用方式或需要报告的内容。请记住，您无法报告未存储的数据。
答案 2 :(得分：1)
这是一种可能的解决方案，但它不是很灵活。如果出现新类型的问题，则必须更改数据库。
另一个解决方案是将所有这些不同的表放入一个具有键值对字段的表中。这种方法的缺点是你必须在应用程序中定义密钥，数据库无法检查是否所有信息都存在。
这是您必须考虑的因素。可以有更多的解决方案，但我现在都无法想到。
答案 3 :(得分：1)
设计时开始考虑如何使用这些数据。您需要运行哪种报告，如何通知人们对问题的更改，您将如何选择分配给任务的人员（您可能需要使用表格来存储可用于工作的人员及其技能组合（他们可以分配什么样的任务），你需要允许什么样的附件以及存储信息的位置（屏幕截图可以帮助你解决问题）。你需要什么样的查找表才能解决问题您的申请是否有所下降？您是否需要进行任何类型的数据审核？您是否需要某些类型的问题需要主管授权？人们可以自动解决，还是需要跟踪他们已经拥有的问题然后再确定谁您是否希望能够确定任务应该完成的数据，以确定什么时候迟到？您说某些停车只能提交某些类型的机票，哪些是存储该数据的表？换句话说s，你真的需要深入了解细节并满足要求。
顺便说一句，不要让任何人谈到你的键值存储，这是在关系数据库中存储数据的绝对最糟糕的方式。您不仅会遇到性能问题，而且还会失去很多能够正确设置字段限制的能力（例如是否需要它们），并且您需要对某些需要频繁转换的信息进行不良数据类型选择。正确的数据类型来执行功能。