mysql - 我应该为具有相似结构的数据单独制作一个表吗

Question

我有许多表包含其“类型/类别/组”字段。该字段引用其各自的表，例如:

item -> item_category、queue ->queue_group、stock -> stock_type、account -> account_type、病人 -> Patient_type 等。它们都具有完全相同的表结构。这是一个简单的例子:

+---------------+---------------+
| name          | type          |
+---------------+---------------+
| id            | INT(AI)       |
| name          | VARCHAR(255)  |
| description   | TEXT          |
+---------------+-------------- +

问题是，我应该为每个数据引用(item_category、queue_group、stock_type、account_type、病人类型等)创建单独的表，还是应该为所有这些数据创建一个引用表？ 例如:

+---------------+---------------+
| name          | type          |
+---------------+---------------+
| id            | INT(AI)       |
| source        | INT           |
| name          | VARCHAR(255)  |
| description   | TEXT          |
+---------------+-------------- +

“source”字段是一个简单的实现示例，用于定义记录属于哪个表。

目的是让那些项目、类别、队列等数据可以在同一个表中查找其“类型/类别/组”字段，以达到少表。我应该使用什么以及每种方法的优缺点是什么？

Answer 1

选择一个或多个引用表实际上是相当任意的。遵循规范化规则，“正确”的选择是为每个引用表提供一个单独的表。这是一个非常合理的做法。

将所有名称放入一个表中可能会提高或降低性能。假设名称的数量为数百甚至数千，那么索引将提供足够的性能——单个较大表的性能影响应该与多个表的性能影响大致相同。实际上，某些查询的性能有可能提高。小引用表通常比数据页小得多，因此一堆小表比大表占用更多的页面。再次强调，虽然对性能有好处，但从性能角度来看，缓存中一些页面的丢失通常不会很明显。

使用单个表的一个重要原因是为了管理此类代码。例如，如果有国际化计划(支持多种语言)，那么将代码放在一处会非常有帮助。同样，如果您决定对描述做出一揽子决定(例如，不允许使用缩写或您想添加简短的描述)，那么将它们放在一个地方会很有帮助。或者，如果您决定将描述从单字节字符更改为国家字符集，那么将它们放在一个位置会有所帮助。

我的结论是，与多个引用表相比，为此目的使用单个引用表对性能的影响最小(除非您正在处理大量代码)。默认方法是单独的表，这是标准化方面的“正确”方法。但是，如果您有理由希望将所有代码放在一个地方，那么这是完全可行的，也是一个合理的解决方案。