1

我有一个当前的数据库结构，似乎为了索引目的而拆分了一些数据。主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...

我的应用程序执行的 SELECT 比 INSERT/UPDATE 多，因此我可以看到在为概览页面（每页 250 多个结果列表）一次查询大量工单时拆分的理论上的好处。然后将在页面上使用更大的详细信息，该页面仅显示一张票及其使用简单 JOIN 的详细信息（在外键上的其他几个 JOIN 中）。

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

4

1 回答 1

1

我觉得这个设计不错。门票表不仅用于显示单张门票信息，还用于计算（即特定日期售出的门票总数）和其他分析（该供应商售出多少张门票？）。

添加tickets_info 将增加tickets 表的大小，但没有任何好处，但有可能增加对tickets 表的访问时间。我假设门票表上的良好索引应该可以保证您的安全，但 MySql 不是列式数据库，所以我希望具有大 varchar 或博客字段的行需要更多资源。

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

所以我的建议是保持原样:)

于 2013-10-09T22:37:18.977 回答