数据库与纯文本

Question

在处理小型项目时，您认为将数据存储在简单文本文件，哈希表等中的收支平衡点与使用真实数据库相比如何？对于具有简单数据管理要求的小型项目，真正的数据库是不必要的复杂性并且违反了YAGNI。但是，在某些时候，数据库的复杂性显然是值得的。有什么迹象表明你的问题对于简单的ad-hoc技术来说过于复杂，需要一个真正的数据库？

注意：对于习惯于企业环境的人来说，这可能听起来像一个奇怪的问题。但是，我的问题领域是生物信息学。我的大多数编程都是原型，而不是生产代码。我主要是域专家，其次是程序员。我的大多数代码都是以算法为中心的，而不是以数据管理为中心的。这个问题的目的主要是让我弄清楚如果我学会在我的代码中使用适当的数据库而不是我通常使用的更多临时技术，我可以节省多少工作。

Answer 1

1）并发。您是否有多人访问同一数据集？如果你推出自己的系统，它将以一种可扩展的方式代理所有不同的读者和作者。

2）格式化和关系：你的数据是不是完全适合表结构的东西？长核苷酸序列和类似的东西？那不是很方便的表格数据。

另一个例子：没有人会考虑像Photoshop这样的软件以关系格式存储PSD，因为数据结构并不适合这种类型的存储或查询模式。

3）ACID（＃1的推论）：如果原始性，一致性，完整性和持久性不是平面文件的挑战，那么请使用平面文件。

Answer 2

我认为在某些时候你会错过数据库的查询功能，但你可以考虑一些简约的数据库选择：

• SQLite（很棒，几乎符合SQL-92标准）
• shsql
• SQL Server Compact

Answer 3

对我来说，一旦我必须以涉及多个关系的方式查询我的数据，就会越过这条线。在磁盘上关联两个平面数据结构非常简单，但是一旦我们超越了这一点，基于集合的语言（如SQL和正式的数据库关系）实际上会降低复杂性。

Answer 4

我只会在非常特殊的情况下编写自己的磁盘格式。重用其他人的代码几乎总是更快。

对于关系数据，我会使用SQLite。对于键/值对，我会使用BerkeleyDB（可能通过KiokuDB）。对于简单的对象，我会使用JSON或YAML，但仅限于我只有少数。

使用SQLite和BDB，“真正的数据库”实际上是两行代码。这很难被击败。

Answer 5

小项目的问题在于，在我们了解之前它们会变得更大。一旦他们这样做，我们就开始错过了sql功能。

总是设计成如果需要可以在以后使用数据库，而不会撕掉应用程序的一半。

Answer 6

完全取决于特定于域的应用程序需求。很多时候，直接文本文件/二进制文件访问可以非常快速，高效，并且为您提供操作系统文件系统的所有文件访问功能。

此外，您的编程语言很可能已经有一个内置模块（或很容易制作）用于特定解析。

如果您需要的是多个附加（INSERTS？）和顺序/少数访问很少/没有并发，文件是可行的方法。

另一方面，当您对并发性，非顺序读/写，原子性，原子权限，数据本质等关系要求时，您最好使用关系数据库或OO数据库。

SQLite3可以实现很多功能，它非常轻便（300kb以下），符合ACID标准，用C / C ++编写，并且非常普遍（如果它还没有包含在你的编程中）语言 - 例如Python-，肯定有一个可用）。它甚至可以用于大到1GB的db文件，可能更多。

如果你的要求更大，甚至没有讨论，那就去找一个成熟的RDBMS。

Answer 7

对于您在生物信息学中开发的应用程序类型，您经常执行一次性应用程序（通常是定义计算工作流程的脚本）来回答特定问题，并且您不太可能在您之后重复使用这些应用程序回答了你的问题 因此，您应该避免创建数据库来存储结果，因为毕竟您不会非常使用它们的功能。

您可能会查询某些Web服务，文件或数据库，对从不同来源收集的数据运行一些本地算法，并生成一些表格或结构化输出格式（xml，json等）。

为此，我建议您使用Knime等工作流工具（或Inforsense KDE，Accelrys的Pipeline pilot或Snaplogic之类的商业解决方案，因为它们允许您以各种格式和位置（rdbms，平面文件，web服务）查询数据，运行算法，并构建功能强大的Web应用程序，使您可以轻松地将工作流程发布给用户，并让他们在特定点进行交互）。

如果您的原型“增长”并且您必须在工作流输出的数据之上构建更多功能，并且如果原型的输出不可能每天都发生变化，那么存储子集的原因是明智的决定结果在数据库中。这使您可以插入功能强大的报表工具，如BusinessObjects，Crystal报表，jasper报表或其他可用的报表解决方案，并以比电子表格或csv文件更好的形式向用户显示数据。

最后，一些开发框架将使您的选择更加明显：如果您使用MVC框架构建Web应用程序，您的数据可能会驻留在RDBMS中（但请不要将基因组序列放在表中专栏:-)）。

总而言之，这取决于您对每个特定应用的需求，视具体情况而定。

Answer 8

在软件中，我通常可以将值存储在XML配置文件或注册表中，例如，软件选项。一旦我需要持久化对象，我就会转移到数据库，因为与关系和报告可以提供的长期影响相比，前期成本并不差。

Answer 9

对于生物信息学，您可能对此感兴趣：Blast on DB。正在研究这个问题的人是我的一个朋友并且有一个关于快速相似性序列搜索的工作，他发现自己创建自己的二进制存储比使用数据库更好。

我不知道有关他的解决方案的具体细节，但你可能可以交换一个或两个ideias邮件给那个人，甚至共享代码。

Answer 10

您是否需要/想要SQL查询？

是否有多人想要访问数据？

您的数据是否相关？

如果您对这些问题的回答是否定的，那么您（可能）不需要完整的数据库。

Answer 11

首先，我考虑一下：

1. 数据库最初的大小：表＃，行数
2. 它会以多快的速度增长？
3. 是否经常查询数据？

例如，如果我要创建个人食谱应用程序，我知道我可能会添加50个最喜欢的食谱，每年添加不超过5个食谱。话虽如此，我可以很容易地通过没有数据库，因为数据存储的大小对查询的影响最小。

也就是说，我可能会将数据库用于任何发生数据输入和查询的应用程序（即使是一个小型的个人配方应用程序）。我认为它不会增加很多开销，特别是当您的框架（例如Rails）允许您保持数据库哑（主要是表，索引和约束）时。如果我决定扩大规模，它可以减少我最终必须移植到数据库的可能性。

Answer 12

如果你知道你的数据格式，平面文件，如果更快/更容易开发，将没有问题。如果您希望您的记录格式在开发过程中经常更改，那么我建议ALTER TABLE是您的朋友。平面文件也会更快（如果你关心速度），除非你希望在许多文件组合中实现相当的连接。

在开发过程中使用RDBMS的真正好处是可以灵活地修改数据模式，以及通过查询轻松访问数据。

良好的设计将确保您的数据访问层保持相对隔离（因为关注点分离）所以如果值得的话，稍后重新编写数据库应该是一个相当简单（如果单调乏味）的事情。或者，当然，如果您使用数据库来开发结构，那么一旦这些结构结晶化以便获得性能，您可以随后将应用程序恢复为平面/索引文件。

Answer 13

使用您最熟悉的持久性技术，并进行充分扩展。

YAGNI至少意味着“不要将新技术添加到您的个人堆栈中，除非您无法使用已经存在的任何内容来提高效率。”

对于我们中的许多人来说，我们对数据持久性的舒适区域是SQL。对某些人来说，它可能是XML。只是不要自己写（见第2段）。

Answer 14

作为有人也在进行生物信息学研究的人，我建议不要在这些原型项目中使用数据库，除非你确定需要它。如果您在围栏上，请使用无数据库解决方案并坚持使用平面文件。值得注意的是，传统的生物信息学研究人员已采用平面文件路径，这意味着对于大多数类型的数据，都有明确定义的文件格式。如果您决定使用数据库解决方案，可能会损害您与现有研究项目的兼容性。