mysql - 为应用程序设置数据库的更好方法是什么？标准化与现实世界

Question

考虑一下，请为数据库支持的应用程序设置此设置。(在我的例子中，数据库是 MySQL，应用程序是在 Ruby(Rails 3)中，但我认为这对这个问题不重要)

假设我有一个仓库应用。

我有多个具有类别和状态的项目。

例如，包含零件的表格会有一些状态，例如:有货、停产、延期交货和多个类别，例如:IT 硬件、汽车、医疗等。

我还有其他需要状态和类别的表，例如供应商:已批准，停业，新订单:打开、处理、发货、取消。

等等

问题是:

我想如果我想正确规范我的数据库 - 我会有一个名为 categories、categories_types、statuses、statuses_types 的表。

然后我会将所有类别存储在该表中，并且任何属于特定类型的类别(例如零件的所有类别)都会有一个指向 category_type - 零件的外键，等等。类型相同。

这是规范化的方式。

但是我经常看到人们为特定类别创建单独的表格，例如，会有一个名为 part_categories、vendor_categories、order_statuses、part_status 的表。这是一个不太规范化的数据库，但我想当你处理很多表时，它可能会更清晰。

哪种方法更好？您的经验有哪些缺点和优点？我通常使用第一个设置，但我经常看到第二个设置，以至于我开始怀疑我的方法。

谢谢。

Answer 1

我认为这取决于您希望如何与数据交互。第二种方法的好处是很容易看出哪些类别和状态与特定对象(供应商、项目、订单)相关联。请记住，如果您确实使用第一种方法，您可能必须在类别和状态表中有一个类型标识符，以标识该行相关的类别或状态的种类(供应商、项目、订单)。

第一种方法的好处是可以更轻松地为新对象添加状态和类别，而且只有两个表也很简单。当您想要向特定类别或状态添加附加信息时，就会出现问题。例如，如果订单雕像需要有一个有效日期，但元素雕像不应该有一个有效日期。一旦达到这一点，您将不得不转向第二种方法，或者添加一个 effective_date，对于该属性不适用的其他状态，该日期将为 null。

请记住，另一种方法是根本不创建状态和类别表，而是将状态和类别值存储在原始表中。您可以使用 MySQL 或 Rails 中的可枚举 (ENUM) 来完成此操作。在 MySQL 中，ENUM 作为整数存储在数据库中，但它解析为单词值，如“已处理”、“已发货”或“已取消”。这样做的好处是，如果你的状态不经常改变，你就可以少做一个连接，并且更容易读取数据库和 Ruby 模型。在 Ruby 中，ENUM 可以简单地是一个常量列表，这些常量具有与之关联的键(整数)和值(字符串)。您可以在应用程序端使用整数值查询和更新数据库以及单词值。

我相信这两种方法都是合理的，您选择的路径实际上取决于您的需求。如果您打算将数据存储在数据库中，那么请分析您将如何与状态和类别进行交互——您的方法可能会有所不同。哪种方法会更快、更容易查询？哪一个更容易更新或修改？你多久阅读一次；你多久写一次？最后，记住你是敏捷的!通过简单的迁移和一些重构，任何一种方法都可以转换为另一种方法。现在对您的应用程序来说最简单的方法在将来可能不是最好的方法，但这完全没问题。这就是敏捷的伟大之处!