schema - What is a better design for storing user preference in Google App Engine? -


i have object model in google app engine

class userpref(ndb.model):   user_id = ndb.keyproperty(kind='user')   setting_a = ndb.booleanproperty(default=true)   setting_b = ndb.booleanproperty(default=true)   setting_c = ndb.booleanproperty(default=true) 

recently have rename attribute , prompts me thinking better design:

a) use 3 rows capture 1 row of information in original design

class userpref(ndb.model):   user_id = ndb.keyproperty(kind='user')   setting_name = ndb.stringproperty()   setting_value = ndb.stringproperty() 

b) repeated property

class userprefprop(ndb.model):   setting_name = ndb.stringproperty()   setting_value = ndb.stringproperty()  class userpref(ndb.model):   user_id = ndb.keyproperty(kind='user')   prop = ndb.structuredproperty(userprefprop, repeated=true) 

what pro , cons these designs? search setting not important now, change in future

in general, think way go unless have unholy number of preferences:

class userpref(ndb.model):   user_id = ndb.keyproperty(kind='user')   setting_a = ndb.booleanproperty(default=true)   setting_b = ndb.booleanproperty(default=true)   setting_c = ndb.booleanproperty(default=true) 

the reason can add preferences, , unlike relational datastore, won't need modify existing rows them date. example if add setting_d above schema midway through project, existing entries have none value returned setting_d until property populated.

i think having setting_name , setting_value properties misses point of ndb. kind of schema useful in relational databases need know entire schema ahead of time. since can dynamically add properties ndb model, there's no reason not make each preference own property.


Comments

Popular posts from this blog

c - Bitwise operation with (signed) enum value -

xslt - Unnest parent nodes by child node -

YouTubePlayerFragment cannot be cast to android.support.v4.app.Fragment -