我正在考虑的应用程序一目了然是"自由格式"数据库。笔记和人工制品的集合。但是，与此同时，系统中还有一些更高级别的结构。

我的10秒钟餐巾纸设计需要将单个"条目"存储在小文件(也许是XML)中，并按目录进行组织，然后使用Lucene之类的方法对整个集合进行索引。

其前提是，人们"与系统""交互"将是微不足道的，因为他们只需要"将文件放入正确的位置"即可。由于它们是简单的文本文件，因此可以由任何程序(例如脚本语言)生成，并且可以在必要时甚至由文本编辑器生成。

详细信息是维护索引以及任何其他可能的关系。

从理论上讲，在启动时，程序可以扫描目录以查找更改的文件并更新索引。它甚至可以在后台执行此操作。我不认为这是一个非常漫长的过程，因为我不希望有1000个条目。但是，如果大小过大，仅在有指示时才进行系统扫描始终是一种选择。

或者，我可能要求使用"新文件"更新某些特殊文件，或者系统可以在启动时检查的某些东西。

另一种选择是使用其他格式而不是单个文件。使用某种数据库，它们只是一角钱。但是通过这样做，突然之间，这些数据实际上对临时用户是"不透明的"。这使得脚本编写以及此类脚本变得更加困难。

现在，我可以使用具有广泛支持的SQLLite之类的东西，并发布数据库架构。或者我在想可以在应用程序中创建服务层。

如果使用Java编写，则可以发布该工具可以使用的Java API，但前提是也必须使用Java编写。

或者，我可以将API公开为轻量级的Web服务(基于HTTP的POX或者基于HTTP的REST)。如今，HTTP支持越来越广泛。这将要求该应用程序正在运行才能使用任何实用程序。

与一切一样，这是一个平衡。我认为文件解决方案更简单，效率可能更低，但可能会限制内部复杂性。

该API可能功能更强大，但更难使用，并且肯定对临时用户没有用。

我们如何看待这种问题？

解决方案

尽管我不能声称知道哪种解决方案最适合需求，但我会第二次猜测一个允许用户不受限制地访问我的数据胆量的设计。我猜总体设计取决于新文件的添加频率，访问频率和存储的信息类型。

吻

正如我们所说，文件解决方案更简单，因此应该是赢家。只需计划使数据存储块成为易于更换的模块(SoC)，并仅增加所需的复杂性即可。

绝对是一个嵌入式数据库作为主要数据存储。这将使我们避免麻烦，使文件夹结构保持预期的状态。搜索，索引编制也将更快。用户可以通过复制单个文件来迁移或者备份其数据。我们可以利用全文搜索以及许多SQL查询和功能。

然后，我们可以使用"导出"选项。导出到文件系统将构建先前描述的XML层次结构。我们还可以轻松导出到单个文件，XML，CSV等。从这些导出中导入也是一种选择。

最后，如果我们在内部足够干净地分离数据库访问，则可以将该API暴露给用户，作为API示例。

因此，将嵌入式数据库用作主要数据存储可以轻松地为我们提供所有其他选择，以及数据库的性能。

我会使用文件格式(并以某种方式发布访问代码作为参考植入，以便人们可以进行I / O)