对于很少的数据集，我的工作策略通常是将其粘贴到文本文件中，但是以我的经验，这可能会给开发带来麻烦。数据通常来自数据库，如果不是，则设置/存储数据所涉及的过程通常隐藏在代码中。使用数据库，我们通常可以看到所有可用数据以及与其他数据的关联方式。

有时，对于非常小的数据集，我只是将它们存储在代码的内部数据结构中(例如Perl哈希)，但是当需要更改时，则由开发人员掌握。

那么，如何处理少量不经常更改的数据呢？我们是否设置了何时使用数据库表或者文本文件或者..的标准？

我很想只使用数据库表来存储所有内容，但是我不确定是否对此有任何影响。

编辑：对于上下文：

我被要求在网站上放一些公司的新联系表，以后会不定期添加。除非公司没有联系电子邮件地址，..这些公司内部的用户却有(因为他们通过自己的帐户发布工作)。现在，我们需要一种"推测性应用程序"类型的功能，并且该表单需要一个电子邮件地址才能将这些应用程序发送到。但是我们也不想将电子邮件地址作为属性放置在表单中，否则垃圾邮件发送者只能将其用作开放的电子邮件网关。显然，我们需要与公司建立ID-> contact_email类型的关系。

因此，我可以将一列添加到具有数百万行的表中，而该行实际上将使用约20次，或者可以创建一个新表，该表最多将容纳约20行。通常，我们过去的处理方式只是创建一个讨厌的文本文件并从那里读取它。但这会造成维护方面的噩梦，并且当依赖于数据的数据发生更改时，经常会查看这些文本文件。也许这是该过程的错，但是我只是想听听对此的看法。

解决方案

将其放入数据库中。如果它很少更改，则将其缓存在中间层。

立即想到的示例是适合作为枚举存储的内容，以及适合存储在"查找"数据库表中的内容。

我倾向于用一条规则"画线"，如果这将导致数据库中的列包含映射到枚举值的"幻数"，则该枚举应确实作为查找表存在。如果它与数据库中存储的数据无关(例如，应用程序配置数据而不是用户生成的数据)，则始终是枚举。

当然，这取决于我们开发来使用该数据集的软件工具的用户，而不论其大小如何？

可能只是他们知道Excel，所以工具将不得不解析他们创建的.csv文件。

如果是为开发人员编写的，那么谁在乎我们使用什么。但是，我不喜欢将包含次要或者临时数据的数据库弄乱。

我们有一个标准的配置文件格式(key：value)和一个处理它的类。我们只在所有项目上使用它。通常，我们只是为我们的应用程序(移动电话开发)设置持久属性，因此这是适当的做法。青年汽车

在程序访问数据库的情况下，我将所有内容存储在其中：易于备份和移动数据。

对于没有数据库访问权限的小型程序，我将数据存储在.net设置中，这些设置存储在xml文件中，这当然是c＃的功能，因此它可能不适用于我们。

无论如何，我确保将所有数据存储在一个地方。通常是一个数据库。

如果这些是类似配置的小型数据，那么我将使用一些简单且通用的格式。 ini，json和yaml通常都可以。 Java和.NET爱好者也喜欢XML。简而言之，使用一些我们可以轻松读取到内存中对象的东西，而不必理会它。

我将其添加到主表中的数据库中：

• 备份和恢复(我们确实要恢复此文本文件，对吗？)
• 临时查询(因为我们可以执行此操作，所以它将使用SQL工具并将其连接到其他数据库数据)
• 如果数据库列为空，则对它的存储要求应该是最小的(如果在Oracle表的末尾是NULL列，则什么都没有)
• 如果我们希望拥有多个应用程序服务器，则将更加容易，因为我们无需保留一些额外配置文件的多个副本。
• 将其放入小儿童桌只会使设计复杂化，而不会带来任何真正的好处

无论如何，我们很可能已经将数据库中的同一行作为处理的一部分，因此性能不太可能成为问题。如果不是，则可以将其缓存在内存中。

我们是否考虑过sqlite？它是基于文件的，可以解决感觉，"只是文件可能会起作用"(零配置)，但这是一个非常好的数据库，并且伸缩性非常好。它支持许多API，并且有许多用于管理它的前端。