Re: [google-appengine] Re: Datastore design question
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.
Re: [google-appengine] Re: Datastore design question
i got alot of user meta data, i save them on another db model called
usermeta which is referencekey to the user model key. under the usermeta i
write duplicated data from the user table too such as user key id as string
and much more. i usually pull the usermeta only and use the user model just
for authentication keeping it clean and to the purpose.
-
Cheers,
public static function AlonCarmel() {
//Contact me
var email = 'a...@aloncarmel.me';
var twitter = '@aloncarmel';
var web = 'http://aloncarmel.me';
var phone = '+972-54-4860380';
}
* If you received an unsolicited email from by mistake that wasn't of your
matter please delete immediately. All E-mail sent from Alon Carmel is
copyrighted to Alon Carmel 2008. Any details revealed in e-mails sent by
Alon Carmel are owned by the Author only. Any attempt to duplicate or
imitate any of the Content is prohibited under copyright law 2008.
On Mon, Jun 28, 2010 at 9:17 AM, Robert Kluin robert.kl...@gmail.comwrote:
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.comgoogle-appengine%2bunsubscr...@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.comgoogle-appengine%2bunsubscr...@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.comgoogle-appengine%2bunsubscr...@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.
Re: [google-appengine] Re: Datastore design question
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.comgoogle-appengine%2bunsubscr...@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.
