Azure 表存储设计问题：使用 1 个表存储多种类型是一个好主意吗？
我只是想知道是否有任何有 Azure 表存储经验的人可以评论一下使用 1 个表来存储多种类型是否是一个好主意？
我想这样做的原因是这样我可以进行交易。不过，我也想从开发的角度了解一下，这种方法操作起来容易还是麻烦？到目前为止，我正在使用 Azure 存储资源管理器来协助开发，并且在一个表中查看多种类型一直很混乱。
举个例子，假设我正在设计一个博客社区网站，如果我将所有博客文章、类别、评论存储在一张表中，我会遇到什么问题？另一方面，如果我不这样做，那么我如何确保类别和帖子的一致性（假设 1 个帖子可以有一个 1 类别）？
或者人们是否有其他不同的方法来使用表存储来解决这个问题？
谢谢。
I'm just wondering if anyone who has experience on Azure Table Storage could comment on if it is a good idea to use 1 table to store multiple types?
The reason I want to do this is so I can do transactions. However, I also want to get a sense in terms of development, would this approach be easy or messy to handle? So far, I'm using Azure Storage Explorer to assist development and viewing multiple types in one table has been messy.
To give an example, say I'm designing a community site of blogs, if I store all blog posts, categories, comments in one table, what problems would I encounter? On ther other hand, if I don't then how do I ensure some consistency on category and post for example (assume 1 post can have one 1 category)?
Or are there any other different approaches people take to get around this problem using table storage?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的目标是实现完美的一致性，那么使用单个表是实现这一目标的好方法。然而，我认为你可能会让事情变得更加困难，并且得到的回报很少。我之所以这样说，是因为表存储极其可靠。如果您正在处理非常非常重要的数据，那么事务就很棒，但在大多数情况下，例如博客，我认为您最好只 1) 允许极小比例的不一致数据和 2) 处理失败以更手动的方式。
在同一个表中存储多种类型时遇到的最大问题是序列化。当前大多数表存储 SDK 和实用程序都旨在处理单一类型。话虽这么说，您当然可以手动处理多个模式（即将对象反序列化为包含所有可能属性的主对象）或直接与 REST 服务交互（即不通过 Azure SDK）。如果直接使用 REST 服务，则必须自己处理序列化，从而可以更有效地处理多种类型，但代价是您需要手动执行通常由 Azure SDK 处理的所有操作。
这样做确实没有正确或错误的方法。两种情况都可以，只是哪个最实用而已。我个人倾向于为每个表放置一个模式，除非有充分的理由不这样做。我认为您会发现表存储在不使用事务的情况下也足够可靠。
您可能需要查看 Windows Azure 工具包。我们设计该工具包是为了简化一些更常见的 Azure 任务。
If your goal is to have perfect consistency, then using a single table is a good way to go about it. However, I think that you are probably going to be making things more difficult for yourself and get very little reward. The reason I say this is that table storage is extremely reliable. Transactions are great and all if you are dealing with very very important data, but in most cases, such as a blog, I think you would be better off just 1) either allowing for some very small percentage of inconsistent data and 2) handling failures in a more manual way.
The biggest issue you will have with storing multiple types in the same table is serialization. Most of the current table storage SDKs and utilities were designed to handle a single type. That being said, you can certainly handle multiple schemas either manually (i.e. deserializing your object to a master object that contains all possible properties) or interacting directly with the REST services (i.e. not going through the Azure SDK). If you used the REST services directly, you would have to handle serialization yourself and thus you could more efficiently handle the multiple types, but the trade off is that you are doing everything manually that is normally handled by the Azure SDK.
There really is no right or wrong way to do this. Both situations will work, it is just a matter of what is most practical. I personally tend to put a single schema per table unless there is a very good reason to do otherwise. I think you will find table storage to be reliable enough without the use of transactions.
You may want to check out the Windows Azure Toolkit. We have designed that toolkit to simplify some of the more common azure tasks.