加载XML“缓存”与查询数据库。缺点？

Question

对于只读应用程序，我目前将数据存储在关系数据库中，但不是通过应用程序查询它，而是每晚将数据（包括其关系）写入XML文件。

当然，它不是很多数据 - XML代表的对象少于1000个。

然后，通过客户端代码，我正在加载该数据，并在必要时“查询”它。

不需要写操作 - 应用程序的唯一功能是搜索和显示。

我开发了这样的应用程序，无论是查询数据库还是加载的xml都可以非常轻松地进行切换，因此我可以比较性能。

我发现，例如全文搜索（如此）是加载XML方法的即时等。

但是，我知道这种方法存在缺陷，如果你们中的任何人能够帮助我充实时间以及为什么这是一种有效的方法，我将不胜感激。

提前致谢。

Answer 1

当您将XML加载到良好的XML处理引擎中时，它会构建适当的数据结构以加速XPath查询或一般的树遍历。

当您将数据保存在关系数据库中并对其进行查询时，查询优化器会构建一个查询计划，该计划也将以某种优化的方式访问数据。

哪种方法最适合您完全取决于查询的性质。

请注意，加载XML文档并在每次客户端调用上解析它可能非常昂贵，除非您使用某种应用程序服务器将已解析的XML树保留在内存中，否则数据库查询很可能是一种更好的方法，因为1000条记录可以使整个表适合缓存。

Answer 2

这听起来对我有用。

如果数据的大小非常大并且可能会损害您的可用内存，或者以一种线程安全问题的方式共享数据，那么就会出现这样的缺陷。

但你说它很小而且只读，所以对我来说听起来不错。保持数据接近所需的位置是每个硬件设计人员都能理解的。

您说它存储为XML，但我假设您每天读取一次文件，解析并将其存储在内存中的DOM对象中，并使用XPath进行查询。 XPath性能是否足以满足您的需求？这将是我唯一关注的问题。

Answer 3

这一切都归结为资源管理。如果您有资源来运行查询，那么这是一条更好的道路，因为您的数据是“实时”的，而不是具有缓存然后解析它的XML文件。如果您担心性能，除非您查询数千万行数据，我不会太担心。我们有一个包含大约60多个客户端的盒子，它们可以整天运行查询，并且盒子实际上可以很好地运行。在大多数情况下，XML解析对服务器的压力比查询压力大。