Question

我有一个当前的数据库结构，似乎为了索引目的而拆分了一些数据。主tickets表具有更多“精简”字段，如外键，整数和日期，tickets_info表具有可能更大的数据，如文本字段和blob。这是一个好主意继续，或者我应该把表结合起来吗？

例如，当前结构看起来像这样（假设与索引上的外键一对一的关系）：

`tickets`
--------------------------------------------
id | customer | vendor | opened
--------------------------------------------
 1 |       29 |      0 | 2013-10-09 12:49:04

`tickets_info`
--------------------------------------------
id | description           | more_notes
--------------------------------------------
 1 | This thing is broken! | Even longer...

我的应用程序比INSERT / UPDATE更多的SELECT，所以当一个概述页面（每页250多个结果列表）一次查询大型故障单列表时，我可以看到拆分的理论上的好处。然后，在显示一张票的页面上使用更大的细节，使用简单的JOIN（在外键上的其他几个JOINS中）显示其详细信息。

这些表目前是MyISAM，但是一旦我重组它们，我将把它们转换为InnoDB，如果这有任何区别的话。目前tickets表中有大约33列，tickets_info表中有4列; tickets_info表可能有更多列，具体取决于安装（我实现的类似于PHPBBv3的“自定义字段”）。

Answer 1

我觉得这个设计很好。故障单表不仅用于显示单个故障单信息，还用于计算（即在特定日期内售出的故障单总数）和其他分析（销售该故障的故障数量？）。

添加tickets_info将增加您的故障单表的大小而没有任何好处，但存在增加故障单表访问时间的风险。我假设在ticket表上有一个好的索引应该保证你的安全，但MySql不是一个柱状数据库，所以我希望一个包含大varchar或blog字段的行需要更多的资源。

除此之外，如果您使用ticket_info进行单一票证查询，我认为您在查询该表时已经获得了良好的性能。

所以我的建议是保持原样：）

组合或单独的表

1 个答案: