数据库字段中的 XMLSerialized 对象。这是好的设计吗？
假设我有一张存放博客的桌子。 该架构如下所示：
ID (int)| Title (varchar 50) | Value (longtext) | Images (longtext)| ....
在“图像”字段中，我存储与博客关联的图像的 XML 序列化列表。
我应该为此目的使用另一张桌子吗？
Suppose i have one table that holds Blogs.
The schema looks like :
ID (int)| Title (varchar 50) | Value (longtext) | Images (longtext)| ....
In the field Images i store an XML Serialized List of images that are associated with the blog.
Should i use another table for this purpose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，您应该将图像放在另一个表中。同一字段中有多个值表示数据非规范化，并且使数据库难以使用。
与所有规则一样，也有一些例外情况，将具有多个值的 XML 放入数据库的一个字段中是有意义的。第一条规则是：
如果满足这一点，则可能有多种原因将数据放在一个字段中：
Yes, you should put the images in another table. Having several values in the same field indicates denormalized data and makes it hard to work with the database.
As with all rules, there are exceptions where it makes sense to put XML with multiple values in one field in the database. The first rule is that:
If that is fulfilled, there can be a number of reasons to put the data together in one field:
我当然会使用另一张桌子。如果您使用 XML，当您需要检查并更新对所有图像的引用时会发生什么？ （您是否愿意执行
Update blog_images Set ...，或者解析每行的 XML，进行更新，然后为每行重新生成更新的 XML？I would certainly use another table. If you use XML, what happens when you need to go through and update the references to all images? (Would you just rather do an
Update blog_images Set ..., or parse through the XML for each row, make the update, then re-generate the updated XML for each?嗯，它有点“内部平台”，但它会起作用。单独的表将允许更好的图像查询，尽管在某些 RDBMS 平台上，这也可以通过 XML 类型列和 SQL/XML 来实现。
如果这些数据只需是不透明的存储，那么也许可以。但是，请记住，您通常必须将整个 XML 返回到应用程序层才能对其执行任何有趣的操作（或者：根据平台，使用 SQL/XML，但我建议不要这样做，因为数据库不是大多数情况下是进行此类处理的地方）。
我对所有其他情况的建议：单独的表格。
Well, it is a bit "inner platform", but it will work. A separate table would allow better image querying, although on some RDBMS platforms this could also be achieved via an XML-type column and SQL/XML.
If this data only has to be opaque storage, then maybe. However, keep in mind you'll generally have to bring back the entire XML to the app-tier to do anything interesting with it (or: depending on platform, use SQL/XML, but I advise against this, as the DB isn't the place to do such processing in most cases).
My advice in all other cases: separate table.
这取决于您是否需要查询实际图像数据本身。如果您发现可能需要查询某些图像或具有某些属性的图像，那么最好以不同的方式存储该图像数据。
否则，就保持原样。
但请记住，仅在需要时才将字段包含在 SELECT 中。
That depends on whether you'd need to query on the actual image data itself. If you see a possible need to query on certain images, or images with certain attributes, then it would probably be best to store that image data in a different way.
Otherwise, leave it the way it is.
But remember, only include the fields in your SELECT when you need them.
未必。您只需确保在不需要时没有在查询中选择图像字段。但是，如果您想对架构进行非规范化，您可以使用另一个表，并在需要图像时执行
join。Not necessarily. You just have to ensure that you are not selecting the images field in your queries when you don't need it. But if you wanted to denormalize your schema you could use another table and when you need the images perform a
join.