代码之家 › 专栏 › 技术社区 › David McLaughlin

如何处理小数据集?

theory database

David McLaughlin · 技术社区 · 16 年前

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

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

那么,如何处理不经常更改的小数据集呢?您是否设置了何时使用数据库表或文本文件或..的条件?

我很想使用一个数据库表来处理所有的事情,但我不确定是否会有任何影响。

编辑: 语境:

我被要求在网站上为一些公司提供一份新的联系表格,以后还会有更多的表格需要添加。但是,公司没有联系电子邮件地址。这些公司内部的用户会这样做(就像他们通过自己的帐户发布工作一样)。不过,现在我们需要一个“推测性应用程序”类型的功能,表单需要一个电子邮件地址来发送这些应用程序。但我们也不想将电子邮件地址作为属性放在表单中,否则垃圾邮件发送者可以将其用作开放的电子邮件网关。所以很明显,我们需要与公司建立ID->联系人电子邮件类型的关系。

所以,我可以在一个表中添加一个列,该表有数百万行,字面上大约20次,或者创建一个最多可以容纳20行的新表。通常,我们过去处理这个问题的方法只是创建一个讨厌的文本文件并从中读取它。但这会造成维护噩梦,而且当这些文本文件依赖于更改的数据时,它们经常会被检查。也许这是这个过程的一个错误,但我只是想听听关于这个的观点。

8 回复 | 直到 16 年前

Javier 16 年前

如果这些是类似配置的小数据,我会使用一些简单和通用的格式。ini、json和yaml通常都可以。Java和.NET爱好者也喜欢XML。简而言之,使用一些你可以很容易地读取到内存中的对象并忽略它的东西。

Mitch Wheat Scott Wisniewski 16 年前

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

Rob 16 年前

立即想到的例子是,将哪些内容存储为枚举是合适的,将哪些内容存储在“查找”数据库表中是合适的。

我倾向于用这样的规则“画线”,即如果它将导致数据库中包含映射到枚举值的“幻数”的列,那么枚举应该作为查找表存在。如果它与存储在数据库中的数据(例如应用程序配置数据而不是用户生成的数据)无关,那么它就是一个枚举。

JeeBee 16 年前

当然,这取决于您开发的软件工具的用户使用数据集,而不管数据大小如何?

可能只是他们知道Excel,所以你的工具必须解析他们创建的.csv文件。

如果它是为开发人员编写的,那么谁在乎您使用什么。不过,我不喜欢用小数据或临时数据来混乱数据库。

Airsource Ltd 16 年前

我们有一个标准的配置文件格式(key:value)和一个类来处理它。我们只在所有项目中使用它。大多数情况下,我们只是为我们的应用程序(移动电话开发)设置持久属性,所以这是一个适当的事情。牛传染性胃肠炎病毒

Sam 16 年前

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

对于没有数据库访问权限的小程序,我将数据存储在.NET设置中,该设置存储在XML文件中-当然,这是C的一个功能,因此它可能不适用于您。

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

Jeffrey Knight 16 年前

你考虑过吗 sqlite ?它是基于文件的,它可以满足您的“仅仅是一个文件就可以做到”(零配置)的感觉,但是它是一个非常好的数据库,并且可以很好地扩展。它支持许多API,并且 numerous front ends 管理它。

WW. 16 年前

我将把它添加到主表中的数据库中:

备份和恢复(是否要恢复此文本文件,对吗?)
临时查询(因为您可以这样做,它将是一个SQL工具,并将其连接到其他数据库数据)
如果数据库列为空,则对它的存储要求应是最低的(如果它是Oracle中表末尾的空列,则不需要任何内容)
如果您想拥有多个应用程序服务器会更容易,因为您不需要保留一些额外配置文件的多个副本。
把它放在一个小孩的桌子上只会使设计复杂化,而不会带来任何真正的好处。

作为处理的一部分,您很可能已经转到数据库中的同一行,因此性能不太可能是问题。如果没有,可以将其缓存到内存中。