您能否举例说明使用 Berkeley DB XML 的情况
我正在尝试阅读有关 Berkeley DB XML，我认为我真的可以使用开发人员的博客文章或概要，说明他们遇到问题时发现 Berkeley DB 顶部的 XML 层正是解决该问题的确切方法。
也许我没有明白，但看起来它们都是进程内数据库，最终您会将 XML 解析为对象或数据，那么为什么不首先存储解析的数据，而不是存储为 XML 呢？
I'm trying to read through the documentation on Berkeley DB XML, and I think I could really use a developer's blog post or synopsis of when they had a problem that found the XML layer atop Berkeley DB was the exact prescription for.
Maybe I'm not getting it, but it seems like they're both in-process DBs, and ultimately you will parse your XML into objects or data, so why not start by storing your data parsed, rather than as XML?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最终我希望我的数据以某种合理的格式存储。
如果该数据以 XML 形式开始，并且我想使用 XQuery 检索它/它们，而不使用 XML 层，那么我必须编写大量代码来自己执行 XQuery，而且可能更糟的是要知道我的 XML 足够好，能够为其拥有合理的存储系统。
相反，只要系统性能允许，我就可以忘记后端的那部分，而只关心我的 XML 文档和向上（即用户）级别，而将其余部分保留为黑匣子。 它为我提供了 B-DB 存储优势，但我可以从以文档为中心的角度来使用它。
Ultimately I want my data stored in some reasonable format.
If that data started as XML and I want to retrieve it/them using XQuery, without the XML layer, I have to write a lot of code to do the XQuery by myself, and perhaps even worse to know my XML well enough to be able to have a reasonable storage system for it.
Conversely, so long as the performance of the system allows, I can forget about that part of the back end, and just worry about my XML document and up (i.e. to the user) level and leave the rest as a black box. It gives me the B-DB storage goodness, but I get to use it from a document-centric perspective.