Table Storage 的数据存储结构，其实与 ASP.NET 的 Profile 行为非常像，资料不是由栏位归档，而是由 XML 做组织。例如下列的代码：

　　实际储存在 Table Storage 中的数据如下图：

　　请注意 Data 栏位，那个栏位就是储存这个 Entity 的所有属性，属性以名称作为标签名称，其实值以标签的 InnerText 所保存，这个技巧被广泛用在很多的系统中，架构上也类似笔者曾发表的 Profile 架构设计。用 XML 来管理半结构化的资料，可以降低设计多个表格的负担，但它的缺点就是会受限数据类型 (因为要储存在 XML)，因此 Table Storage 的 Entity 栏位，只支持下列的数据类型：

　　同时，为了要让 ADO.NET Data Services REST API 可以顺利执行，Table Storage 的 Entity 名称与属性名称有下列的限制：

　　1. 表格名称必须是英文字母，不可以由数字开头，不分大小写，且长度最小 3 个字元，最长 63 个字元。

　　2. 栏位名称必须要让 XML 可以接受，且最长是 255 字元，最好是依据 C# 的识别项规范来命名。

　　而 PartitionKey 以及 RowKey 则有下列的限制：

　　1. 不可以包含 “\”，”/”，”#”，以及 “?” 四种字元。

　　2. 在每一次对 Entity 的新增，修改与删除时，都必须要设定 PartitionKey 以及 RowKey。

　　3. PartitionKey 最长 1KB，RowKey 最长也是 1KB。

　　上面针对 Table Storage 的讨论，其来源都是 SDK 以及在 Development Storage 资料库中所得到的资讯，也许会和正式的 Windows Azure Table Storage 的实体架构有所出入。

　　原文地址