保存对象的最佳方式及其在 MySQL 数据库中的类型

Question

使用面向对象的编程语言，我的情况是我有一个对象，其中一个属性是对象的类型。当我将它保存到数据库时，我总是创建两个 table，一个用于对象本身，另一个用于对象类型（id、名称）。然后我将 typeId 分配给对象并为 ObjectType table 创建一个外键。我不确定这是否正确，因为：

• 我使用整个 table 来保存很少的记录（5-10 种可能的对象类型）并且它们很少更新。
• 我需要在两个 table 之间进行 JOIN 以显示对象类型的名称。
• 在代码中，我声明了与类型 table 具有相同 ID 的常量（以便在编程和将类型分配给对象时进行操作），我不喜欢这种冗余。

另一种选择是使用字符串并将其直接保存在对象的 table 中，但这听起来不太好，因为搜索速度会比使用 typeId 慢，而且没有关于所有内容的列表可能的类型。更改一种类型的名称也更复杂。你能告诉我在这种情况下最好的做法是什么吗？

Answer 1

在这种情况下，您有 3 个选择：

1. 可变字符
2. 枚举字段
3. 另一个加入table（查找table）。

你有 5 个评估参数：

1. 冗余
2. 可扩展性
3. 可修改性
4. 性能
5. 简单

Varchar:

1. 非常差（您应该复制值）
2. 很好（可以轻松添加新类型）
3. 非常糟糕（您应该将所有插入的数据更改为相同的值）
4. 优秀（基于参考）
5. 优秀（易于用作其他领域和 ORM）

枚举字段：

1. 好（DBMS控制冗余）
2. 非常非常差（基于参考）
3. 非常非常差（基于参考）
4. 优秀（基于参考）
5. 非常好（一些 ORM 的行为类似于字符串字段 - 请参阅 this reference）

另一个加入table（查找Table）:

1. 优秀（ER正常法）
2. 优秀（ER正常法）
3. 优秀（ER正常法）
4. 正常（可能不好 - 如果速度如此重要）
5. 正常（取决于程序员）

参考文献：

请在此处查看性能分析 (Enum Fields VS Varchar VS Int + Joined table: What is Faster?)。

在此处查看枚举的优点和缺点 (8 Reasons Why MySQL's ENUM Data Type Is Evil)。

请参阅 mysql here 中的查找 table 和 Varchar 示例。

最后：根据您的评估参数，您可以选择合适的选项。

另一种可能性是在数据库中只使用一个整数并在源代码中管理所有内容。我不把它放在评估中，因为它不是数据库设计。它是编程方法。