这似乎是一个常见的问题，但我找不到它。也许“系统价值”是错误的短语。
无论如何，“系统值”是指系统对给定概念的内置值。例如，如果我有一个类别列表（例如墨西哥，美国，意大利等等），你会在哪里存储它们？你会对它们进行硬编码（可能是枚举）还是放入数据库？
如果您说硬编码，如果用户可以创建新类别，您的答案会改变吗？显然你必须将新的存储在数据库（或像xml这样的其他媒介）中，但是你会将标准系统值保留为硬编码，然后在运行时合并它们吗？
答案 0 :(得分：2)
有一些符号值是应用程序的真常量（例如pi的值，或整数可以表示的最大值）。将它们放入源代码中就可以了。
如果您预见到用户需要更改值，则需要将它们放入外部配置（或数据库）文件中。代码中有一些值，配置中有些值令人困惑;对于列表，可能也很难让用户删除他不想要的值。
对于配置文件中的值，您仍希望将它们保持在源代码管理下。为此，常见的选项是：
答案 1 :(得分：1)
如果用户可以添加，编辑或删除列表中的值，那么显然在应用程序中对它们进行硬编码并不是一个可行的选择。但是，如果用户不控制列表，并且列表相对较短，那么对它们进行硬编码（例如枚举）是完全有效的选择，即使它们必须经常更改，只要您有一个机制，可以轻松地将客户端应用程序更新到最新版本。这种方法显然比将它们存储在外部数据源中简单。
但是，我想不出太多的用途，比如一个国籍列表，而不是数据选项列表中的数据，这些数据最终会出现在数据库中，在这种情况下，从列表中提取列表更有意义通过适当的关系约束绑定到其他表的数据库中的表。我继承了多个应用程序，它们在两个地方维护了一个选项列表：数据库表和编译到应用程序中的匹配枚举。这种情况被称为“不好”。
答案 2 :(得分：0)
我认为你回答了自己的问题。
如果项目的生命周期中某些事情永远不会改变（祝你好运），那么我会使用数组或哈希。通常我有一个函数返回它。
但通常我最终会存储数据库中可能发生变化的所有内容。
如果您希望区分原始用户提交的类别，请添加默认值为0的列，并且不要在插入时设置它。将原始值设置为1。
答案 3 :(得分：0)
如果值列表与应用程序逻辑紧密相关，我通常不会将它们与应用程序一起存储，如枚举或类似。无论如何，您都必须使用新逻辑更新应用程序，并且将值存储在数据库中只会增加某人在不更新逻辑的情况下错误地添加或删除值的可能性。
但是，您给出的示例（“墨西哥”，“美国”，“意大利语”）是数据库中存储的主要候选者。此列表似乎可能经常更改，并且应用程序代码中的任何内容都不需要更新以处理新值。如果你决定处理Elbonian食物，你需要做的就是更新数据库，你就完成了。如果您不需要，则没有理由强制进行应用程序更新。
答案 4 :(得分：0)
其他人给出了很好的答案。我只想补充一点，你给出的国籍的例子是你不应该将它们编码为数据库中的ENUM，因为它们太可能改变了。
仅对一小组保证不会更改的值使用ENUM。即从集合中添加或删除值在逻辑上是荒谬的。如果您的值集可能会更改，请将它们存储在查找表中，这样您只需使用UPDATE / INSERT / DELETE命令即可更改数据值。重新定义ENUM是元数据更改，这通常很昂贵。
请注意，如果您认为“可能”的值列表不会更改，或者“没有理由”让他们更改，或者任何其他此类限定规则，您可以假设某个经理将要求集合在某个时刻发生变化。
PS：ENUM是特定于MySQL的数据库类型。其他一些数据库可以通过CHECK约束实现类似的结果。
答案 5 :(得分：0)
将您的数据放入数据库。没有硬编码。
这些值将更改，或者至少会被扩展。如果他们将以任何方式与数据相关联，那么请帮自己一个忙，然后将它们放入数据库中。这不仅可以节省您添加其他值的时间，而且还允许它们参与数据库级别的参照完整性约束。
当我看到帖子的标题时，我笑了，因为我的数据库几乎总是包含一个名为SystemValues的表，用于存储配置程序操作的“一次性”值，例如（例如）用于存储生成的输出的根文件夹。还有一个匹配的存储过程GetSystemValue（Key，ValueIfNull）来检索它们。
对于允许自定义到用户级别的项目，我还包括一个名为UserValues的表，其中包含一个额外的UserID列，以及一个GetUserValue（Key，UserID，ValueIfNull）存储过程。
对于那些不是面向数据库的应用程序，Windows为您提供了一个不错的“免费”数据库 - 注册表 - 或者您可以将自己的配置文件放在一起。