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.
