在处理小型项目时，您认为将数据存储在简单的文本文件、哈希表等中与使用真实数据库相比，盈亏平衡点是什么？对于具有简单数据管理需求的小型项目，真正的数据库是不必要的复杂性，并且违反了 YAGNI。然而，在某些时候，数据库的复杂性显然是值得的。有哪些迹象表明您的问题对于简单的 ad-hoc 技术来说过于复杂并且需要一个真实的数据库？
注意：对于习惯于企业环境的人来说，这可能听起来像是一个奇怪的问题。但是，我的问题领域是生物信息学。我的大部分编程都是原型，而不是生产代码。我主要是领域专家，其次是程序员。我的大部分代码都是以算法为中心的，而不是以数据管理为中心的。这个问题的主要目的是让我弄清楚如果我学会在我的代码中使用适当的数据库而不是我通常使用的更多临时技术，从长远来看我可以节省多少工作。
1）并发。您是否有多个人访问同一个数据集？然后，如果您推出自己的系统，它将非常参与以可扩展的方式代理所有不同的读者和作者。
2) 格式和关系：您的数据是否与表格结构不完全吻合？长核苷酸序列之类的东西？这不是很方便的表格数据。
另一个例子：没有人会考虑实施像 Photoshop 这样的软件来以关系格式存储 PSD，因为数据结构并不真正适合这种类型的存储或查询模式。
3) ACID（有点像 #1 的推论）：如果原子性、一致性、完整性和持久性不是平面文件的挑战，那么就使用平面文件。
对我来说，一旦我必须以涉及多个关系的方式查询我的数据，就会越界。关联磁盘上的两个平面数据结构相当简单，但是一旦我们超越了这一点，像 SQL 和正式的数据库关系这样的基于集合的语言实际上会降低复杂性。
我认为在某些时候您会错过数据库的查询功能，但您可以考虑一些简约的数据库替代方案：
我只会在非常特殊的情况下编写自己的磁盘格式。重用别人的代码几乎总是更快。
对于关系数据，我会使用 SQLite。对于键/值对，我会使用 BerkeleyDB（可能通过 KiokuDB）。对于简单的对象，我会使用 JSON 或 YAML，但前提是我只有几个。
使用 SQLite 和 BDB，“真正的数据库”实际上是两行代码。很难打败它。
小项目的问题在于它们在我们不知不觉中变得更大。一旦他们这样做了，我们就开始缺少 sql 功能。
始终进行设计，以便以后可以在需要时使用数据库，而无需撕开一半的应用程序。
这完全取决于特定领域的应用程序需求。很多时候，直接文本文件/二进制文件访问可以非常快速、高效，并为您提供操作系统文件系统的所有文件访问功能。
此外，您的编程语言很可能已经有一个用于特定解析的内置模块（或者很容易制作）。
如果您需要的是许多附加（插入？）和顺序/很少访问很少/没有并发，那么文件就是要走的路。
另一方面，当您对并发性、非顺序读/写、原子性、原子权限、您的数据本质上是关系型等方面的要求时，使用关系型或 OO 数据库会更好。
使用SQLite3可以完成很多工作，它非常轻巧（小于 300kb），符合 ACID，用 C/C++ 编写，并且非常普遍（如果它尚未包含在您的编程语言中，例如 Python），肯定有一个可用的）。即使在 1GB 甚至更多的 db 文件上，它也很有用。
如果您的需求更大，甚至不会进行讨论，请选择成熟的 RDBMS。
对于您在生物信息学领域开发的那种应用程序，您经常使用一次性应用程序（通常是定义计算工作流程的脚本）来回答特定问题，并且在您回答问题后不太可能重复使用这些应用程序.
因此，您通常应该避免创建数据库来存储结果，因为毕竟您不会过多地使用它们的功能。
您可能会查询一些 Web 服务、文件或数据库，对从不同来源收集的数据运行一些本地算法，并生成一些表格或结构化输出格式（xml、json 等）。
为此，我建议您使用 Knime 等工作流工具（或Inforsense KDE、Accelrys 的Pipeline Pilot或Snaplogic等商业解决方案，因为它们允许您以各种格式和位置（rdbms、平面文件、Web 服务）查询数据)、运行算法并构建功能强大的 Web 应用程序，使您可以轻松地将工作流发布给用户并让他们在特定点进行交互）。
如果您的原型“增长”并且您必须在工作流输出的数据之上构建更多功能，并且如果您的原型输出不太可能每天都在变化，那么将结果的子集存储在数据库。这允许您插入强大的报告工具，如 BusinessObjects、Crystal 报告、jasper 报告或任何可用的报告解决方案，并以比电子表格或 csv 文件更好的形式向您的用户显示数据。
最后，一些开发框架将使您的选择更加明显：如果您使用 MVC 框架构建 Web 应用程序，您的数据很可能将驻留在 RDBMS 中（但请不要将基因组序列放在表列中：- ））。
总而言之，这是一个个案选择，取决于您对每个特定应用程序的需求。
在软件中，我通常可以将值存储在 XML 配置文件或注册表中，例如软件选项。一旦我需要持久化对象，我就会转移到数据库，因为与关系和报告可以提供的长期影响相比，前期成本并没有那么糟糕。
对于生物信息学，您可能对此感兴趣：Blast on DB。从事这项工作的人是我的一个朋友，他从事快速相似性序列搜索方面的工作，他发现在这一点上让自己的二进制存储比使用数据库更好。
我不知道他的解决方案的具体细节，但你可能可以交换一两个想法，邮寄给这个人，甚至共享代码。
您需要/想要 SQL 查询吗？
是否有多个人想要访问数据？
你的数据是相关的吗？
如果您对这些问题的回答是否定的，那么您（可能）不需要完整的数据库。
首先，我会考虑：
例如，如果我要创建一个个人食谱应用程序，我知道我可能会添加 50 个最喜欢的食谱开始，并且每年添加不超过 5 个食谱。话虽如此，我可以在没有数据库的情况下轻松过关，因为数据存储的大小对查询的影响很小。
也就是说，我可能会将数据库用于发生数据输入和查询的任何应用程序（甚至是小型个人食谱应用程序）。我认为它不会增加很多开销，尤其是当您的框架（例如 Rails）允许您保持数据库哑（主要是表、索引和约束）时。如果我决定扩大规模，它减少了我最终必须移植到数据库的机会。
如果您知道数据的格式，平面文件，如果更快/更容易开发，就可以了。如果您希望您的记录格式在开发过程中经常更改，那么我建议 ALTER TABLE 是您的朋友。除非您希望在许多文件组合中实现等效的连接，否则平面文件也往往会更快（如果您关心速度）。
在开发期间使用 RDBMS 的真正好处是您可以灵活地修改数据模式，并且可以轻松地通过查询访问数据。
良好的设计将确保您保持数据访问层相对隔离（因为关注点分离），因此如果值得的话，以后对数据库进行返工应该是一件相当简单（如果乏味）的事情。或者，当然，如果您使用数据库来开发您的结构，您可以在这些结构结晶后将应用程序带回平面/索引文件以获得性能。
使用您最熟悉的任何持久性技术，并充分扩展。
YAGNI 至少意味着“不要将新技术添加到您的个人堆栈中，除非您无法使用已经存在的任何东西来提高工作效率。”
对于我们中的许多人（大多数？）来说，我们对数据持久性的舒适区是 SQL。对于某些人来说，它可能是 XML。只是不要自己写，直到（见第 2 段）。
作为也从事生物信息学研究的人，我建议不要将数据库用于此类原型项目，除非您确定它需要它。如果您犹豫不决，请使用无数据库解决方案并坚持使用平面文件。同样重要的是要注意，传统的生物信息学研究人员走的是平面文件路线，这意味着该领域中大多数类型的数据都有明确定义的文件格式。如果您决定使用数据库解决方案，它可能会损害您与现有研究项目的兼容性。