Fatal编程技术网

Database design 寻找一些关于DB设计的反馈

database-design

Database design 寻找一些关于DB设计的反馈,database-design,feedback,Database Design,Feedback,我目前正在开发一个票务系统，允许我们的用户根据自己的需要提交票务。i、 e.如果部门“A”提交问题单，他们可能会有某些类型的问题类别（如“供应品”或“打印机”）以及与所选类别相关的详细信息。 我已经制定了一个部分数据库设计，我正在寻找一些反馈。我从来没有自己建立过一个系统，所以我有点紧张 这是我的db设计的草稿 问题表 Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | -----------

我目前正在开发一个票务系统，允许我们的用户根据自己的需要提交票务。i、 e.如果部门“A”提交问题单，他们可能会有某些类型的问题类别（如“供应品”或“打印机”）以及与所选类别相关的详细信息。 我已经制定了一个部分数据库设计，我正在寻找一些反馈。我从来没有自己建立过一个系统，所以我有点紧张

这是我的db设计的草稿

问题表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
设备发布详情表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
供应发布详情表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
网络发布详细信息表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
注释表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------
提前感谢

这是一个可能的解决方案，但它不是很灵活。如果出现新类型的问题，则必须更改数据库

另一种解决方案是将所有这些不同的表放在一个表中，其中包含一对键值字段。这种方法的缺点是，您必须在应用程序中定义密钥，而数据库无法检查是否存在所有信息

这是你必须考虑的。可以有更多的解决方案，但我现在想不出任何解决方案。

我会拆分您的问题表，以便将问题和任务分开。另外，我将添加一个issue types表，并向issues添加一个IssueTypeId列

问题 身份证， IssueTypeId， 由， CreateDate， 地位 所有者

发行类别 身份证， 名字

作业 身份证， 发布ID， 分配给， 转让日期， 活跃的

这将允许在以后需要时为一个问题分配多个人。它还允许记录从某个问题上取消分配人员的历史。问题类型条目如下：1：设备，2：供应，3：网络

有几个不同的问题类型可能可以管理，但是如果你有很多，用Ikke建议的键/值表方法替换“细节”表可能更好。

你的设计非常出色。一个单独的表格包含每种类型问题的详细信息正是正确的方法

不要听从那些认为您应该拥有键/值对的人的建议。这种方法使一些事情变得容易，但当你尝试做其他事情时，它很快就会变成一场噩梦。您可以使用完整的RDBMS。用它

每个表格中的每一行都代表了一个关于世界的真实命题。DB设计越能反映您试图跟踪的重要现实，您的情况就越好

如果将来发现您需要跟踪更多详细信息，请添加更多列。如果发现有其他问题类型，则添加更多表。问题类型表不添加任何内容

当需要创建报告或对这些数据进行分析时，遵循这一原则将获得巨大的回报

你应该考虑OG的建议：允许每个问题的多个受让人，或者跟踪分配的历史。这取决于如何使用系统，或者需要报告什么。请记住，您不能报告未存储的数据。

在设计时，请开始考虑如何使用这些数据。您需要运行什么类型的报告，如何通知员工问题的更改，如何选择要分配给任务的人员（您可能需要表格来存储可用于工作的人员及其技能集（可以分配给他们什么类型的任务），您需要允许哪些类型的附件以及在何处存储这些信息（屏幕截图可以帮助您解决问题）。在应用程序的下拉列表中，您需要什么样的查找表？您需要任何类型的数据审核吗？您需要主管授权某些类型的问题吗？是否可以自动对人员进行识别？或者在确定谁可用之前，您需要跟踪他们的车牌上已有的内容。您希望吗能够确定任务应该完成的数据，以便确定事情何时延迟？您说过某些部门只能提交某些类型的票据，存储该数据的表在哪里？换句话说，您确实需要深入了解细节并满足要求

顺便说一句，不要让任何人说服你进入键值存储，这绝对是在关系数据库中存储数据最糟糕的方式。你不仅会有性能问题，而且会失去很多对字段进行正确限制的能力（例如是否需要字段）对于一些需要频繁转换到正确数据类型才能执行功能的信息，您不得不选择糟糕的数据类型。

键值表在大多数情况下都是一个糟糕的选择，因为它们会降低性能。同意分配的想法，我可能还有一个任务表，以便每个分配的人都可以e指定要完成的特定任务，并可以将其标记为已完成。这取决于问题的复杂程度。这不是对总体设计问题的回答，但由于您需要反馈，我将添加一个（无可否认）不挑剔的注释。我喜欢数据库对象名称与字段名称一致。例如，使用“CreatedBy and CreatedDate”和“AssignedTo and AssignedDate”而不是混合动词时态。