Design Golf: моделирование адреса в appengine, он же AddressProperty?

Question

Сегодня я проводил рефакторинг некоторого кода и снова посетил старого друга, класс Address (см. Ниже). Мне пришло в голову, что в нашем приложении мы не делаем ничего особенного с адресами - никаких запросов, только легкая проверка и частая сериализация в JSON. Единственные «полезные» свойства с точки зрения разработчика - это метка и персона.

Итак, я рассмотрел вопрос о рефакторинге модели Address для использования собственного AddressProperty (см. Ниже), что мне кажется полезным, но вне всяких сомнений я не вижу каких-либо убедительных преимуществ.

Какой метод вы бы выбрали, почему и какие компромиссы определяют это решение?

# 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

Учитывая, что вам не нужно запрашивать адреса, и учитывая, что они имеют тенденцию быть достаточно маленькими (в отличие, скажем, от большого двоичного двоичного объекта), я бы предложил пойти с последним.Это сэкономит пространство и время (извлекая его) - единственным реальным недостатком является то, что вы должны реализовать свойство самостоятельно.

Answer 2

Если вы хотите немного отличаться, вы всегда можете хранить данные в одной таблице в виде структур, а затем иметь другую таблицу для поиска и метаданных.