反规范化数据模型：django/sql ->应用程序引擎
我刚刚开始了解非关系数据库，因此我想寻求一些帮助，将这些传统的 SQL/django 模型转换为 Google App Engine 模型。
该示例用于事件列表，其中每个事件都有一个类别，属于一个场地，并且一个场地附有许多照片。
在 django 中，我会像这样对数据进行建模：
class Event(models.Model)
title = models.CharField()
start = models.DatetimeField()
category = models.ForeignKey(Category)
venue = models.ForeignKey(Venue)
class Category(models.Model):
name= models.CharField()
class Venue (models.Model):
name = models.CharField()
address = models.CharField()
class Photo(models.Model):
venue = models.ForeignKey(Venue)
source = models.CharField()
如何使用 App Engine 模型完成等效操作？
I'm just starting to get my head around non-relational databases, so I'd like to ask some help with converting these traditional SQL/django models into Google App Engine model(s).
The example is for event listings, where each event has a category, belongs to a venue, and a venue has a number of photos attached to it.
In django, I would model the data like this:
class Event(models.Model)
title = models.CharField()
start = models.DatetimeField()
category = models.ForeignKey(Category)
venue = models.ForeignKey(Venue)
class Category(models.Model):
name= models.CharField()
class Venue (models.Model):
name = models.CharField()
address = models.CharField()
class Photo(models.Model):
venue = models.ForeignKey(Venue)
source = models.CharField()
How would I accomplish the equivalent with App Engine models?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里没有任何必须非规范化才能与 App Engine 配合使用的情况。您可以将ForeignKey更改为ReferenceProperty，将CharField更改为StringProperty，将DatetimeField更改为DateTimeProperty并完成。将类别存储为字符串而不是引用可能更有效，但这取决于使用上下文。
当您开始设计查询时，非规范化变得很重要。与传统 SQL 不同，您无法编写可以访问每个表的每一行的即席查询。您想要查询的任何内容都必须由索引满足。如果您现在运行的查询依赖于表扫描和复杂连接，则必须确保查询参数在写入时建立索引，而不是动态计算它们。
例如，如果您想按事件标题进行不区分大小写的搜索，则必须在写入时在每个实体上存储标题的小写副本。在不猜测您的查询要求的情况下，我无法提供更具体的建议。
There's nothing here that must be de-normalized to work with App Engine. You can change ForeignKey to ReferenceProperty, CharField to StringProperty and DatetimeField to DateTimeProperty and be done. It might be more efficient to store category as a string rather than a reference, but this depends on usage context.
Denormalization becomes important when you start designing queries. Unlike traditional SQL, you can't write ad-hoc queries that have access to every row of every table. Anything you want to query for must be satisfied by an index. If you're running queries today that depend on table scans and complex joins, you'll have to make sure that the query parameters are indexed at write-time instead of calculating them on the fly.
As an example, if you wanted to do a case-insensitive search by event title, you'd have to store a lower-case copy of the title on every entity at write time. Without guessing your query requirements, I can't really offer more specific advice.
可以在 App Engine 上运行 Django
您需要这里的三个应用程序：
http://www.allbuttonspressed.com/projects
此外，此模块使之成为可能跨数据存储方法不直接支持的外键关系进行联接：
...它使您想要联接的字段非规范化，但有一些限制 - 不自动更新非规范化值，因此仅真正适合静态值
Django 信号为自动非规范化提供了有用的起点。
It's possible to run Django on App Engine
You need a trio of apps from here:
http://www.allbuttonspressed.com/projects
Additionally, this module makes it possible to do the joins across Foreign Key relationships which are not directly supported by datastore methods:
...it denormalises the fields you want to join against, but has some limitations - doesn't update the denormalised values automatically so is only really suitable for static values
Django signals provide a useful starting point for automatic denormalisation.