views:

339

answers:

1

Coming from a relational database background, as I'm sure many others are, I'm looking for some solid guidelines for setting up / designing my datastore on Google App Engine. Are there any good rules of thumb people have for setting up these kinds of schema-less data stores? I understand some of the basics such as denormalizing since you can't do joins, but I was wondering what other recommendations people had.

The particular simple example I am working with concerns storing searches and their results. For example I have the following 2 models defined in my Google App Engine app using Python:

class Search(db.Model):
    who = db.StringProperty()
    what = db.StringProperty()
    where = db.StringProperty()

    createDate = db.DateTimeProperty(auto_now_add=True)

class SearchResult(db.Model):
    title = db.StringProperty()
    content = db.StringProperty()

    who = db.StringProperty()
    what = db.StringProperty()
    where = db.StringProperty()

    createDate = db.DateTimeProperty(auto_now_add=True)

I'm duplicating a bunch of properties between the models for the sake of denormalization since I can't join Search and SearchResult together. Does this make sense? Or should I store a search ID in the SearchResult model and effectively 'join' the 2 models in code when I retrieve them from the datastore? Please keep in mind that this is a simple example. Both models will have a lot more properties and the way I'm approaching this right now, I would put any property I put in the Search model in the SearchResult model as well.

+3  A: 

Don't duplicate the properties if they'll always be the same between the SearchResult and a Search. If a SearchResult should have a reference to a Search, keep a ReferenceProperty pointing to the Search. This basically stores the related Search's Key in the model.

class SearchResult(db.Model):
    search = db.ReferenceProperty(Search, required=True)
    # other stuff...

I also highly recommend you watch some of the App Engine videos from last year's Google I/O (and from 2008), in particular this one by Brett Slatkin, and this one by Ryan Barrett. They're all pretty helpful videos if you have the time, but I found those two in particular to be really great.

Jason Hall
Excellent, thanks man.
jamesaharvey