Consider the classic example of blog data modelling, where we have a Blog
entity with many properties, and we want to list the latest blogs in a page.
It makes sense to denormalize the BlogPost
entity into a BlogPostSummary
entity which will be shown in the list view, avoiding fetching and deserializing many unwanted properties.
class BlogPost(db.Model):
title = db.StringProperty()
content = db.TextProperty()
created = db.DateProperty()
...
class BlogPostSummary(db.Model):
title = db.StringProperty()
content_excerpt = db.TextProperty()
The question is: which entity should hold the indexed properties? There are 3 options:
1. Index properties in both
- Pros:
- Easy query on both entities.
- Cons:
- Maintaining denormalized indexes is expensive.
2. Index properties in main entity only
- Pros:
- Indexing properties in the main entity is more safe, as the denormalized entity is treated as redundancy.
- Cons:
- Querying the list view will need a double roundtrip to datastore: One to key-only query for
BlogPost
entities, followed by a batch get forBlogPostSummary
.
- Querying the list view will need a double roundtrip to datastore: One to key-only query for
3. Index in denormalized entity only
- Pros:
- The list view can be easily built by a single query.
- Cons:
- The main entity cannot be queried by those properties anymore.
- The indexes occupy more space when the denormalized entity is a child of the main entity.
Which option would work better? Are there other options?
Would the double round trip to datastore in option 2 be a problem?
This is an abstract question that does not have a "correct" answer. The choice of a data model depends on specific requirements of a project, including:
By the way, there is another way to model data in the Datastore - using child entities. For example, blog posts may be child entities of a blog entity. This way you can retrieve all blog posts with a single query by providing a parent key - without storing post IDs or keys in the blog entity or blog ID/key in the post entities.