您什么时候选择将 XML 存储在关系数据库中？
可能的重复：
为什么我会选择在关系数据库中存储和操作 XML？
尽管这个问题从表面上看似乎是对先前已提出的问题的重复，但我会预先声明事实并非如此。我的问题不是如何从关系数据库存储或检索 XML。现在的问题比这个更根本：
您通常在数据库中以 XML 格式存储什么类型的数据？为此，您的设计决策是什么？您是否愿意通过将模型的某些部分放入 XML 简介中来放弃数据库的“关系”方面？首选项或配置文件等内容可以作为 XML 存储在关系数据库中，但您应该这样做吗？
Possible Duplicate:
Why would I ever choose to store and manipulate XML in a relational database?
Although this question on the surface appears to be a rehash of what's already been previously asked, I'll state up front that it is not. My question is not how to store or retrieve XML from a relational database. The question at hand is much more fundamental than that:
What type of data do you usually store in XML format in your database? What are your design decisions for doing so? Are you willing to give up the 'relational' aspect of your database by putting certain parts of your model into an XML blurb? Things such as preferences or configuration files can be stored as XML in a relational database, but should you do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
绝不。
将具有某种可识别结构的数据存储为 XML（而不是关系数据）意味着放弃关系代数对该数据进行操作的能力。
如果这就是您的真正意图，那么很好，但是请诚实地对待它，根本不用费心使用关系 DBMS，只需将 XML 转储到某个本地/伪本地文件中即可。
（请注意，存储在文件系统中的任何内容也构成数据库，因此该解决方案并不意味着您“不使用数据库”。您只是没有使用关系管理的数据库，而这正是您启动的目的。 ）
Never.
Storing data to which there is some kind of recognisable structure as XML, instead of as relational data, means abandoning the power of the relational algebra to operate on that data.
If that is your very intention, fine, but then be plain honest about it and just don't bother to use a relational DBMS at all, just dump your XML in some local/pseudolocal file.
(Observe that anything stored in a filesystem constitutes a database too, so it's not like that solution means that you are "not using a database". You're just not using one that is managed relationally, which was your very intention to boot.)
我在关系数据库中存储 XML 的经验通常是出于历史目的或作为持久性策略的一部分存储序列化对象，并假设我稍后将检索此 XML 并将其重新水化为对象。
My experience with storing XML in a relational database is usually storing serialized objects for either historical purposes or as part of a persistence strategy with the assumption that I will later retrieve this XML and rehydrate it into an object.
恕我直言，将 XML 放入数据库的唯一原因是您需要与项目交互、编辑或更改数据。如果您只是读取和使用 XML 数据，只需将其放入文件中即可。但是，如果要使用应用程序修改或添加该数据，则最好使用 DB，并且您根本不需要 XML，因为表将描述数据的结构。
The only reason, IMHO, to put XML in a database is if you need to interact, edit, or change the data with your project. If you are simply reading and using the XML Data, just throw it in a file. But if that data is being modified or added to with the application, its better to use a DB for that and you don't really need XML at all, since the table will describe the structure of the data.
您的代码可能希望按以下方式处理 XML 数据：
xml数据类型，或其他 DBMS 中的等效数据类型。Your code may want to process XML data in the following ways:
xmldata type in SQL Server 2005 or above, or the equivalent in other DBMSs.当数据本身不需要有关系时，我倾向于存储 xml 简介（或其他不透明数据，例如序列化的 json）。
I tend to store xml blurbs (or other opaque data such as json serialized) when the data itself does not need to have relationships.
我使用这些条件在数据库中存储 XML 数据。
我没有时间开发关系表（实际上，我有时只是为了启动并运行原型而以这种方式开始）。
数据太大且结构复杂，无需付出很大的努力即可分解为表格
一般来说，我喜欢将关系数据存储在我的数据库，但想象一下我有一个对象，它代表呈现网页所需的所有数据（我的意思是所有内容，字体，图像等），它会非常复杂，将其存储在表结构中实际上只会起到作用造成维护问题 - 结构是流动的。它还会导致我的查询问题 - 想象一下我需要执行的连接数量以及所需的时间。
I use these conditions for storing XML data in a database.
I don't have the time to develop the relational tables (really, I sometimes start off this way just to get a prototype up and running).
The data is much to large and complex in structure to break into tables without considerable effort
In general I like to store relational data in my database, but imagine I have an object that represents all the data required to render a web page (I mean everything, fonts, images the lot), Its going to be incredibly complex, storing it in a table structure will serve to really only casue me maintenace issues - the structure is fluid. it would also cause me query issues - imagine the number joins I would need to do, and the time it would take.