如何在 Google 数据存储区中对实体进行建模
与关系数据库引擎不同，Google App Engine 使用的数据存储不强制执行架构 - 它存储具有各种属性的实体，而不是行和列。尽管如此，仍然应该使用传统的数据库设计吗？
例如，假设我有一个跟踪各种租赁车辆的应用程序。在传统数据库中，我可能有一个 Buses 表，用于跟踪车队中每辆巴士的长度和座位数，以及 Trucks，其中有一列用于记录每辆卡车的负载能力和马力。每辆公共汽车和卡车也有颜色和车牌号。 （如果我想标准化数据库，我可以在 Vehicle 表中分解这些属性）。
在 Google 的数据存储中，我很想简单地将公共汽车和卡车存储为 Vehicle 实体，因为它们共享共同的属性，并添加特定于车辆类型的任何属性。
使用传统数据库模型（其中每个数据存储实体代表一个数据库表）有哪些优点/缺点？
将大实体分解成更小的实体是否更有效？
编辑：
另外，关于使用哪个 API 有什么建议：JDO、JPA 还是数据存储低级 API？
谢谢！
The Datastore used by Google’s App Engine, unlike a relational database engine, does not enforce schemas – instead of rows and columns, it stores entities with various properties. Nevertheless, should one still use a traditional database design?
For example, let’s say I have an application that tracks various rental vehicles. In a traditional database, I may have a Buses table, which tracks the length and number of seats for each bus in the fleet, and Trucks, which has a column for the load capacity and horsepower for each truck. Each bus and truck also has a color and license plate number. (If I want to normalize the database, I could break out these attributes in a Vehicle table).
In Google’s Datastore, I’d be tempted to simply store buses and trucks as Vehicle entities, as they share common properties, and add whatever properties are specific to the type of vehicle.
What are the advantages/disadvantages to using a traditional database model, where each Datastore entity represents a database table?
Is it more efficient to break large entities into smaller entities?
EDIT:
Also, any recommendations regarding which API to use: JDO, JPA or the Datastore low-level API?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您根本不应该考虑表格。考虑实体。 文档指出：
最佳性能通常是通过对数据进行反规范化来实现的。因此，您可能最好使用两种不同的实体类型：
Bus和Truck，并忽略它们共享某些属性的事实。You should not be thinking about tables at all. Think about entities. The documentation states that:
The best performance is usually achieved by de-normalizing data. So you are probably better off with two distinct entity types,
BusandTruckand ignoring the fact that they share some properties.这是一个困扰我很久的问题。我认为稍后搜索实体的方式对决定设计模型有重大影响。让我受伤的是，在 App Engine 中，您无法使用不等式过滤同一实体的多个属性。
我已经在我的应用程序中使用了 JDO，到目前为止它运行良好。我决定使用它，因为我有这本书，提供了许多现实世界的内容应用程序引擎中的 jdo 查询示例。
我必须对这些属性进行非规范化和拆分才能进行查询。您可以观看 Bret Saltkin 在 Google I/O 上的视频，以更好地了解数据库设计方法。我已经完全掩盖了 我在 Google 应用引擎中进行数据存储区建模的经验见此处。
This was a question that puzzled me for long. I think the way you would want to search on the entity later makes a significant difference in deciding a design model. Some thing that hurt me was that, in App Engine you can't use inequality filters on multiple properties of the same entity.
I have used JDO for my application and it's working fine so far. I decided to use it since this book I had, provided many real-world examples of jdo queries in app engine.
I had to denormalize and split these properties to do the queries. You can watch the Bret Saltkin's video at Google I/O to get a better understanding of db design methods. I've done and entire cover-up of my experience with datastore modelling in Google app engine here.
如果您使用的是 Python，请查看 PolyModel 类。它提供了一种方便的方法来对数据进行非规范化，同时仍然保持不同类型之间的一些逻辑分离。如果您有多种类型，则可以使用 获得与 PolyModel 相同的结果展开。
一般来说，实体的大小对性能的影响很小。实体的数量对性能的影响要大得多。换句话说，支持更少的实体。
正如 klausbyskov 指出的那样，不要用关系数据库来思考。最终，您的应用程序的性能可能会受到影响，因为您将需要进行许多额外的查询和获取。要了解一些主要差异，请查看“掌握数据存储区”文章。
If you are using Python, look at the PolyModel class. It provides a convenient way to denormalize your data, while still keeping some logic separations between different kinds. If you will have many kinds you can achieve the same result as a PolyModel using an Expando.
In general the size of an entity will have little impact on performance. The number of entities has a much larger performance impact. In other words, favor fewer entities.
As klausbyskov pointed out, do not think in terms of relational databases. Ultimately the performance of your app will probably suffer because you will need to make many additional queries and fetches. To understand some of the key differences check out the 'Mastering the Datastore' articles.