谷歌应用引擎数据存储的数据建模与应用开发全解析

### 谷歌应用引擎数据存储的数据建模与应用开发全解析 #### 1. 文本属性特性 特殊的文本属性，如 Email 和 PhoneNumber，仅用于辅助数据解读，不具备额外功能，也不进行输入数据的验证。因为不同国家电话号码和地址的书写格式差异巨大，通用的验证流程没有实际意义。 #### 2. 属性选择 - **日期或时间存储**：若要存储日期或时间，应使用 Date 对象。 - **长文本存储与搜索**：当需要存储长文本并进行搜索时，面临 String 和 Text 属性的选择。首先要考虑是否真的需要对长文本进行索引，因为索引会占用空间和增加成本。可考虑使用 Google 自定义搜索实现全文搜索，未来 App Engine 可能会提供原生全文搜索支持。目前，简单的值可通过较短的 String 字段进行搜索。也可以将长文本存储为 Text，同时将关键词存储在 String 对象中，但这可能需要用户手动指定关键词。还可将长文本分割到多个索引的 String 字段中，但不建议这么做，因为这样可能使索引占用大量空间。 - **字节数组存储**：少于 500 字节且确定不会超过该大小，选择 ShortBlob；在 500 字节到 1MB 之间，选择 Blob；超过 1MB，使用 Google Blobstore。 #### 3. 实体划分 起初难以依靠直觉判断什么是独立实体，可遵循一个临时原则：实体内容应尽量接近屏幕显示内容。随着经验积累，可灵活打破此规则并给出合理决策。以常见的列表视图和详细视图为例，列表元素通常是详细视图元素的片段，逻辑上是同一类实体。但如果详细视图属性众多，为列表视图获取实体时可能会获取大量不必要的属性，导致数据传输量增加。此时，将实体划分，把用于列表视图的值复制到单独的实体中，可节省数据传输量。 #### 4. 实体间关系的创建与维护 - **基本关系**：一个实体可通过值为键的属性与另一个实体建立关系，键包含标识符和实体类型，确保引用的唯一性。键还可能有父级，父子关系在事务中有重要意义，但应尽量避免，除非确实必要。 - **关系方向**：两个实体建立关系时，需确定是 A 引用 B、B 引用 A 还是双向引用，这取决于数据读写时更常从 A 到 B 还是反之。例如，若 A 存储了对 B 的引用，获取 B 较简单；但如果 B 没有对 A 的引用，从 B 获取 A 则需要创建查询并可能需要创建索引。若查询频繁，需重新考虑关系方向。 #### 5. 一对多和多对多关系 - **一对多关系**：当实体 A 与多个 B 实体相关联时，若关联的 B 实体较少，可让 A 存储对所有 B 实体的引用；若关联的 B 实体很多，让所有 B 实体引用 A 更合适，即便读取时可能需要额外查询。 - **多对多关系**：对于多对多关系，需统计每个实体的引用数量。若实体 A 平均引用 n 个 B 实体，实体 B 平均引用 m 个 A 实体，当 m > n 时，选择从 B 到 A 的引用方向可能更合理，但这不是绝对规则，需持续验证数据情况。 #### 6. 数据操作 - **数据读取**：操作