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 <[email protected]> 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 <[email protected]>
>>
>> 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 [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to