Hi Alex, My instinct in this case is that 2 would be your better option. From your description of scenario 1, it sounds like you would be doing a GQL IN query on the ListProperty, which just ends up being multiple GQL = queries under the covers. Also, when querying against a ListProperty, you need to be careful not to run in to issues with exploding indices.
Key lookups are very fast, and should always be the preferred way of querying data. In terms of 'robustness', again, key lookups are always preferred for speed, but neither version coded correctly should have significant issues with robustness. Lastly, your quota question depends on specific implementation, but querying will be more costly in terms of resource usage than key lookups as a general rule. Querying incurs more datastore CPU cost, and depending on the querying will require an index, quota currently limiting applications to 100 indexes. As stated before, you may run up against exploding indexes when using ListProperties: http://code.google.com/appengine/docs/datastore/queriesandindexes.html#Big_Entities_and_Exploding_Indexes -Marzia On Thu, Sep 4, 2008 at 8:34 PM, Alex Epshteyn <[EMAIL PROTECTED]>wrote: > > I'm trying to decide between two data modeling strategies for my app > and wondering which one is faster and more reliable. > > I'll give an example of my use case because this is a fairly common > scenario and this discussion should benefit other developers as well: > > I have a model, UserInfo, with usernames as keys, which makes an > instance fast to retrieve by username with get_by_key_name, and also > enforces the uniqueness constraint for usernames. > > I also want each user to be able to have 0 or more aliases in addition > to their usernames (I'm developing an app with an OpenSocial component > on multiple social networks, in case you're wondering, and want the > user's ID on each network to be an alias of their username). These > aliases should function just like usernames (enable lookup of the > associated UserInfo instance and be unique). In other words, I want > to immitate an instance having multiple keys. > > I'm trying to decide between 2 implementation strategies: > > 1) add an "aliases" ListProperty to UserInfo and use GQL on this > property for lookup. This poses a problem: how to enforce uniqueness > of aliases across the system? Transactions and entity groups don't > fit this case well. > > 2) create a new entity kind called Alias with keys being the aliases > and one ReferenceProperty pointing at the UserInfo instance associated > with this alias. The advantage of this method is that it > automatically enforces the uniqueness constraint using keys. > Performance-wise, this method uses 2 key lookups instead of 1 GQL > query. (It also uses more storage space, but I'm not too concerned > about space) > > What I want to know is: > > a). which one is faster? (1): a GQL query on a ListProperty holding > strings (with average list size = 2 elements) or (2): a > get_by_key_name lookup followed by dereferencing a ReferenceProperty > (2 key look-ups total). > > b). which one is more robust (less likely to throw a datastore error > or timeout)? > > c). how many Database API quota units does each one use? > > and lastly, a more subjective question, > > d). if (1) turns out to be better in all of the above comparisons (a, > b, c), is it worth using (2) just to enforce the uniqueness > constraint. > > Thanks for your time. Hope this discussion will help everyone utilize > the datastore more efficiently! > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
