database - 你如何处理小数据集？

Question

对于非常小的数据集，我工作的策略通常是将它们粘贴到文本文件中，但根据我的经验，这可能是一个令人头疼的开发问题。数据通常来自数据库，如果不是，则设置/存储它所涉及的过程通常隐藏在代码中。使用数据库，您通常可以查看所有可用的数据以及它与其他数据相关的方式。

有时对于非常小的数据集，我只是将它们存储在代码中的内部数据结构中（如 Perl 哈希），但是当需要更改时，它就在开发人员手中。

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

我很想只使用数据库表来处理所有事情，但我不确定这是否有任何影响。

编辑：对于上下文：

我被要求在网站上为少数几家公司添加一个新的联系表，将来还会偶尔添加更多。除了，公司没有联系电子邮件地址。这些公司内部的用户有（因为他们通过自己的帐户发布工作）。不过现在，我们想要一个“推测应用程序”类型的功能，并且表单需要一个电子邮件地址来发送这些应用程序。但我们也不想将电子邮件地址作为属性放入表单中，否则垃圾邮件发送者可以将其用作开放式电子邮件网关。很明显，我们需要一个 ID -> contact_email 类型与公司的关系。

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

Answer 1

把它放在数据库中。如果它不经常更改，请将其缓存在中间层。

Answer 2

立即想到的示例是适合存储为枚举的示例以及适合存储在“查找”数据库表中的示例。

我倾向于“划清界限”的规则是，如果它会导致数据库中的一列包含映射到枚举值的“幻数”，那么该枚举应该真正作为查找表存在。如果它与存储在数据库中的数据无关（例如，应用程序配置数据而不是用户生成的数据），那么它一直是一个枚举。

Answer 3

当然，这取决于您开发的用于使用数据集的软件工具的用户，无论大小如何？

可能只是他们知道 Excel，因此您的工具必​​须解析他们创建的 .csv 文件。

如果它是为开发人员编写的，那么谁在乎你使用什么。但是，我不喜欢使用少量或临时数据使数据库混乱。

Answer 4

我们有一个标准的配置文件格式（键：值）和一个类来处理它。我们只是在所有项目中使用它。大多数情况下，我们只是为我们的应用程序（手机开发）设置持久属性，所以这是一件合适的事情。YMMV

Answer 5

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

对于没有数据库访问权限的小程序，我将我的数据存储在 .net 设置中，这些设置存储在一个 xml 文件中——当然这是 c# 的一个特性，所以它可能不适用于你。

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

Answer 6

你考虑过sqlite吗？它是基于文件的，可以解决您“只需一个文件就可以”（零配置）的感觉，但它是一个非常好的数据库，并且可扩展性非常好。它支持许多 API，并且有许多用于管理它的前端。

Answer 7

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

Answer 8

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

1. 备份和恢复（您确实想恢复此文本文件，对吗？）
2. 即席查询（因为您可以使用 SQL 工具将其连接到其他数据库数据）
3. 如果数据库列是空的，它的存储要求应该是最小的（如果它是 Oracle 表末尾的 NULL 列，则没有）
4. 如果您想拥有多个应用程序服务器会更容易，因为您不需要保留一些额外配置文件的多个副本
5. 将它放入一个小子表只会使设计复杂化，而不会带来任何真正的好处

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