It sounds like the list property can't be appended to without a
transaction?  If so, it seems it'll be better to create two tables,
one for Users and one for Items.

Just to answer the above questions... I expect many reads of the data
and few writes.  I also expect the normal case to have few items (1-2
on avg) and it won't change often.  The key to the Items table would
be user_id-item_name.  Are prefix scans in GQL efficient?  Also, in
terms of data I'm storing about the items, I have ~5-10 fields of
metadata.

For now I'm assuming that the right thing to do here is to split the
data between tables.  Even if it seems to be an unlikely problem now,
I don't want to put myself in a situation where I'm limited by the QPS
that transactions can support.

Thanks,
Phil


On Jun 27, 11:17 pm, Robert Kluin <robert.kl...@gmail.com> wrote:
> The answer to this question depends on several other questions too.
> For example:
>   1) how many items are you expecting?
>   2) how often do a users items change, and how do they get changed
> (the user or something else)?
>   3) what type of querying / reporting do you need to be able to do?
>   4) what type of information would you need to store about each users item?
>
> Robert
>
>
>
> On Sun, Jun 27, 2010 at 9:59 PM, Tom Wu <service.g2...@gmail.com> wrote:
> > Hi Luís,
>
> > If you have a "User" model, with a "items" heavy Property like TextProperty
> > which is not necessary for every query.
> > Which db structure is better ?
>
> > Best Regards
> > Tom Wu
>
> > 2010/6/28 Luís Marques <luismarq...@gmail.com>
>
> >> Hello Phil,
>
> >> Anyone correct me if I'm wrong but you use one of the following
> >> options, among others.
>
> >> You can have a "User" model, with a "items" ListProperty. The pros: if
> >> you have the key for the user (e.g. you can use the email), then with
> >> a simple get (faster than a query) you can retrieve the entity
> >> including the items. Writing a new object is transactional. The cons:
> >> you must always get a set the entire user entity. The entity might get
> >> large if there are a lot of items. If you use custom indexes with the
> >> "items" property the index might get large quickly, especially if you
> >> use more than one ListProperty (exploding indexes).
>
> >> You can have a "User" model, and a "UserItem" whose parent is the
> >> User, making it part of a transaction group. Cons: you have limited
> >> QPS writes to the transaction group (about 1-10 QPS), but that's the
> >> same limitation you have to a standalone User with items. You have to
> >> query (seek) the items, although I wouldn't call that a problem
> >> without profile data. Pros: you can write individual UserItems. You
> >> can have transactions for the user and the items s/he has.
>
> >> You can have a "User" model and a "UserItem" with a User key
> >> reference. Cons: you can no longer have a transaction depending on the
> >> user and the items s/he has. Pros: you can write individual items
> >> without write collisions to the User.
>
> >> You can have a "User" and a flat list (e.g. text, non-indexed) of the
> >> corresponding items. Cons: limits the queries you can make, have to
> >> update all items at once. Pros: better index performance.
>
> >> Etc. I hope it was helpful and correct?
>
> >> Best regards,
> >> Luís
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Google App Engine" group.
> >> To post to this group, send email to google-appeng...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-appengine+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/google-appengine?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-appeng...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to