数据库与纯文本

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

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

1)并发.您是否有多人访问同一数据集？如果您推出自己的系统,那么它将以可扩展的方式为所有不同的读者和作者提供相关服务.

2)格式和关系:您的数据是否不适合表格结构？长核苷酸序列和类似的东西？那不是很方便的表格数据.

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

3)ACID(#1的推论):如果原子性,一致性,完整性和持久性不是平面文件的挑战,那么请使用平面文件.

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

SQLite(很棒,几乎符合SQL-92标准)

shsql

SQL Server Compact

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

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

对于关系数据,我会使用SQLite.对于键/值对,我会使用BerkeleyDB(可能通过KiokuDB).对于简单的对象,我会使用JSON或YAML,但前提是我只有少数几个.

使用SQLite和BDB,"真正的数据库"实际上是两行代码.这很难打败.

小项目的问题在于它们在我们知道之前变得更大.一旦他们这样做,我们就开始缺少sql功能.

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