帮助台数据库设计

Question

帮助台数据库设计

3

我工作的公司对于帮助台系统有着非常特定和独特的需求，因此开源系统都不适用于我们。鉴于这种情况，我使用PHP和MySQL创建了一个自定义系统。它远非完美，但比他们之前使用的系统好得多；相信我！它能很好地满足我们的大部分需求，但我对数据库设置方式有一个问题。以下是主要表格：

ClosedTickets
ClosedTicketSolutions
Locations
OpenTickets
OpenTicketSolutions
Statuses
Technicians

当用户提交帮助请求时，它会进入“OpenTickets”表。技术人员解决问题时，他们会提交包含所做工作描述的条目。这些条目会进入“OpenTicketSolutions”表。当问题得到解决时，最后一个处理该问题的技术人员关闭工单，并将其移动到“ClosedTickets”表中。所有解决方案条目也会被移动到“ClosedTicketSolutions”表中。其他表（位置、状态和技术人员）存在于规范化的意义上（每个位置、状态和技术人员都有一个ID供参考）。

我现在遇到的问题是：

当我想查看所有打开的工单列表时，SQL语句有些复杂，因为我必须左连接“Locations”、“Statuses”和“Technicians”表。各种表中的字段也需要可搜索。请看一下如何在已关闭的工单中搜索由名字包含“John”的任何人提交的工单时，SQL语句是多么复杂：

SELECT ClosedTickets.*, date_format(ClosedTickets.EntryDate, '%c/%e/%y %l:%i %p') AS Formatted_Date, date_format(ClosedDate, '%c/%e/%y %l:%i %p') AS Formatted_ClosedDate, Concat(Technicians.LastName, ', ', Technicians.FirstName) AS TechFullName, Locations.LocationName, date_format(ClosedTicketSolutions.EntryDate, '%c/%e/%y') AS Formatted_Solution_EntryDate, ClosedTicketSolutions.HoursSpent AS SolutionHoursSpent, ClosedTicketSolutions.Tech_ID AS SolutionTech_ID, ClosedTicketSolutions.EntryText
FROM ClosedTickets
LEFT JOIN Technicians ON ClosedTickets.Tech_ID = Technicians.Tech_ID
LEFT JOIN Locations ON ClosedTickets.Location_ID = Locations.Location_ID
LEFT JOIN ClosedTicketSolutions ON ClosedTickets.TicketNum = ClosedTicketSolutions.TicketNum
WHERE (ClosedTickets.FirstName LIKE '%John%')
ORDER BY ClosedDate Desc, ClosedTicketSolutions.EntryDate, ClosedTicketSolutions.Entry_ID

目前我无法同时搜索打开和关闭的工单，我认为使用 UNION 运算符也不适用于我的情况。所以我想知道是否应该将打开和关闭的工单存储在同一张表中，并只有一个字段来指示工单是否已关闭。唯一可以预见的问题是我们已经有太多已关闭的工单（近30,000），所以整个系统可能会变得缓慢。将打开和关闭的工单合并是否是个坏主意？

- Adam Taylor

为什么在你的情况下联合体不起作用？ - Anonymoose

有什么具体和独特的要求吗？我很难相信您无法让众多开源解决方案中的任何一个适用于您。 - Chris K

@Anonymouse：我对MySQL不是特别熟悉，但我认为联合需要表格完全相同，在这种情况下它们并不相同。@Chris Kaminski：我们是一个学区。我们有全职员工和学生。我们需要能够根据他们的作品给学生评分。此外，为了激励学生，我们需要有某种成就系统，类似于RPG。相信我，这对他们非常有效！ - Adam Taylor

3个回答

2

为什么你有四个关于票务的表格？我会将它们归类为一个用于票务和另一个用于解决方案。

- Mike

有两个表格用于存储票务信息，另外还有两个表格用于存储解决方案的条目。这样，多个技术人员可以参与输入解决方案信息。 - Adam Taylor

然后只需添加另一个表格，其中包含解决方案信息、工单ID和技术人员ID，这样就可以创建多对多关系表了。 - Mike

并且一个关闭/打开的布尔值。然后您可以将两个表合并为一个。 - Mike

1

我认为将已关闭和未关闭的工单存储在同一张表中是可行的。您可以创建一个状态字段，其值为0表示关闭，1表示打开，或者您想使用的任何约定。正如其他回答者提到的那样，3万条记录不应该是问题。

希望这可以帮助到您。

- SidC

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- vfilby · Accepted Answer

我会将它们存储在同一张表中。只有当有很多票时，才将它们分成两个表进行优化。不过我认为这不会是一个问题。

在整个大局中，30,000确实很少。数据库可以处理数百万行而不费吹灰之力，只要你有适当的索引（所有连接列和潜在搜索列）。

如果以后出现缓慢的情况，可以将旧的票据归档到归档表中。

总体而言，单表设计更加简洁，可以将相似的数据放在一起。