0

我有一个应该包含研讨会的地方。可以举办研讨会：

  • 内部
  • 在另一个城市
  • 在另一个国家

起初，我只有一个表，所以我使用了枚举。但是现在我有三个无法合并的表，它们都应该有这些信息，客户希望这个字段可以自定义，以便将来添加或删除选项。但是他们说选项的数量是有限的，可能是 5 个左右。

现在，我的问题是，我应该为这个字段使用枚举还是表格？更重要的是，在枚举或表之间做出决定的正确方法是什么？

PS：枚举字段是从数据库中动态检索的，它们没有嵌入到代码中。

4

3 回答 3

1

作为一般经验法则，在应用程序中，在以下情况下使用枚举：

  1. 你的价值观很少改变，并且
  2. 只有几个值。

在以下情况下使用查找表：

  1. 值经常变化，或
  2. 您的客户希望能够实时添加、更改或删除值，或者
  3. 有很多价值观。

如果满足枚举的先前标准并且：

  1. 您需要能够使用应用程序外部的工具来报告数据，或者
  2. 您认为以后可能需要消除枚举以支持纯查找表方法。

您需要为截止点的值数量选择您认为合理的截止值，我经常听到建议在 10 到 15 之间。

如果您使用数据库引擎提供的枚举构造，则前两组规则仍然适用。

在您的具体情况下，我会使用查找表。

于 2012-04-24T15:12:55.110 回答
0

如果在这种情况下元素是固定的，则应使用枚举，如果是可变数据，则enum不应使用。在那些情况下table是更优选的。

我认为在你的情况下表应该没问题。

于 2012-04-24T14:53:02.183 回答
0

我同意关于枚举精简、稍微快一点并在合理使用时降低数据库复杂性的最佳答案（即没有大量且快速变化的值）。

但是：有一些巨大的警告需要考虑：

  • ENUM 数据类型不是标准的 SQL，除了 MySQL 之外，没有多少其他 DBMS 对它有原生支持。PostgreSQL、MariaDB 和 Drizzle（后两者无论如何都是 MySQL 的分支）是我所知道的仅有的三个。如果您或其他人想要将您的数据库移动到另一个系统，那么有人将不得不在迁移过程中添加更多步骤来处理您所有聪明的 ENUM。（来源和更多观点http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/）

  • 大多数 ORM（例如Doctrine）不支持 ENUMS，因为它们不是 SQL 标准。因此，如果您考虑在您的项目中使用 ORM，甚至使用某些东西作为Doctrine Migrations Bundle ，您最终可能会编写一个复杂的扩展包（我已经尝试过）或使用现有的类似Postgresql的扩展包甚至不能为枚举添加更多的伪支持：通过将枚举视为带有检查约束的字符串类型。一个例子：

    CREATE TABLE test (id SERIAL NOT NULL, pseudo_enum_type VARCHAR(255) CHECK(pseudo_enum_type IN ('value1', 'value2', 'value3')) , ...

因此，在更复杂的设置中使用 Enums 的收益确实低于零。

说真的：如果我不是绝对必须（而且我没有），我总是会避免在数据库中使用枚举。

于 2017-04-13T10:23:50.897 回答