Design Golf: modeling an Address in appengine, aka an AddressProperty?

Question

Today I was refactoring some code and revisited an old friend, an Address class (see below). It occurred to me that, in our application, we don't do anything special with addresses-- no queries, only lightweight validation and frequent serialization to JSON. The only "useful" properties from the developer point-of-view are the label and person.

So, I considered refactoring the Address model to use a custom AddressProperty (see below), which strikes me as a good thing to do, but off-the-top I don't see any compelling advantages.

Which method would you choose, why and what tradeoffs guide that decision?

# a lightweight Address for form-based CRUD
# many-to-one relationship with Person objects
class Address(db.Model):
   label=db.StringProperty()
   person=db.ReferenceProperty(collection_name='addresses')
   address1=db.StringProperty()
   address2=db.StringProperty()
   city=db.StringProperty()
   zipcode=db.StringProperty()


# an alternate representation -- worthwhile? tradeoffs?
class Address(db.Model):
   label=db.StringProperty()
   person=db.ReferenceProperty(collection_name='addresses')
   details=AddressProperty()   # like db.PostalAddressProperty, more methods

Answer 1

If you wanted to be a little different you could always store the data in one table as structures and then have another table for lookups and metadata

Answer 2

Given that you don't need to query on addresses, and given they tend to be fairly small (as opposed to, say, a large binary blob), I would suggest going with the latter. It'll save space and time (fetching it) - the only real downside is that you have to implement the property yourself.