Hi Steve, First, on GAE you generally do not need to fear creating lots of records. But I think you are right. If you want to send a report, fetching a few hundred entities could be a major performance drain. I routinely fetch several dozen entities in one fetch for reports without any issues.
That said, I personally use the third technique extensively. I would take into account how you might want to search the data, which it sounds like you have. It sounds like you are not too concerned with querying by the specific transaction data. Perhaps you could use one object per "session" and store individual transaction details encoded in the text property. I favor the third approach over the second because it gives you a bunch of flexibility. You can serialize your entities how ever you want to; I frequently use JSON. In several instances I have found ListProperties to have very poor performance characteristics, even when they are not indexed. With your third technique you can wait to deserialize the additional data, unless / until it is needed. Robert On Sat, Nov 20, 2010 at 13:39, stevep <[email protected]> wrote: > I am developing a small, personal interest "addition / subtraction" flash > card app for my 2nd grade daughter. Looking good re: feedback from her and > some classmates. > Would like to record a transaction each time a child (who has optionally > logged in) solves a card. I'd like to be able to access all the transactions > for a child, and send them as a CSV to the parent who might want to analyze > child's activity. > Got me wondering about how to best architect this. > Transaction will come in via a simple get call. There are a few fields of > information in each trans which I'll likely set up as a delimited string. > Don't know if this would ever be something that would be high volume, but > let's assume this is running at a high number of transactions per second > (the more interesting assumption). Also let's have fun and assume most kids > like doing this and work thru lots of cards (my hope for my daughter at > least.) > Options I'm considering -- appreciate any and all pluses/minuses comments > (no pun intended): > 1) Create a new record for each new transaction with username as indexed > field. Plus: simple (relative to my MySql experience), Minus: too many new > record puts, too many records, inefficient to iterate thru query results > when sending usage data to user's parents. Need to maintain an indexed field > if I want to sort the trans by date created descending (I am pretty sure > this is the case). Overall, I'm pretty sure this is DOA. > 2) Create one record for keyed by username with a List property. Each new > transaction after the first simply gets the record, appends the new data to > the list, and puts the update. If it gets inefficient to have very large > List fields, then might modify this to use one username record up to a list > of let's say 500 items, then create a new rec with a key pointer to it in > the previous rec. Pluses: simple, very quick to iterate list, easy to sort > (with proper delimited string setup). Minuses: unsure about efficiencies of > a List property in an entity if it gets a large count of elements. > 3) Same as (2) except use a Text property instead of a list but concatenate > the new trans with a new delimiter onto the existing text value. > Pluses/Minuses are about the same as (2) except the text would need to be > split before getting an list list to get at the individual transactions. > (Dont' think we will ever search on transaction fields, so the searchable > aspect of a List property adds no value.) > Right now I am leaning toward 2 if List properties stay efficient with > hundreds of entries. Need to stop working on this though, so maybe it will > be 3 since that is about equal to (2), but avoids potential List property > size inefficiencies. > Thanks in advance, > stevep > > -- > 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.
