Is this technique for stat tracking without a database workable?

Question

If I wanted to create a chess game, for iOS, that tracked both player moves (for retracing the progression of a game and for player stats), what would be the simplest route to take?

To clarify, I want to track not only the moves a player has made in a particular game, but how often that player has made that move in past games. For example I want to be able to track:

• How many times a given player has opened by moving the king pawn up two squares (e4) as white, on move number one.
• What is the percentage of time the player responds to white's e4 opening move, with moving his own king pawn to e5?
• What percentage of time does he respond by moving his queenside bishop pawn to c5?

And so on. If it's not clear, the stat tracking system should also be able to report how many times this player, as black, move his queen to h1, on move number 30.

I'm using Parse.com for my back-end as a server (BaaS) service. If I were to create a class that

• writes strings that identify move number, player color, moved piece, algebraic notation of the square (e.g. "d8") to a file, locally in the file system
• saves the file to Parse, and deletes the temporary file from file system
• upon opening the same game in my tableview (a la a "With Friends" game), download this file from Parse, parse through it and retrieve all stats/history, assign all relevant values to variables

Is this plan viable, or is there an easier way?

Answer 1

You can certainly do all of this by simply storing the move list for a game in a text file. That would be the simplest way to store the data, but at the expense of forcing you to build all of the query mechanisms yourself.

Something more structured like an XML or JSON file will probably make querying slightly easier (since you are on iOS, you may want to consider the APIs for reading .plist files, which are effectively the same thing).

It's unclear to me what you are actually using Parse for; your description here makes it sound like it's just a file storage system that is redundant with local storage (do you want to also collect the stats for the opposing player in a peer-to-peer game?). A SQLite DB would serve your described needs just as well and avoid the latency involved with round-tripping this file over the network. If your aversion to using 'a database' stems from not wanting to have something like a SQL Server instance up and running to deal with this data, SQLite (perhaps via CoreData, which will then give you all the NSPredicate-based queries you probably want) is worth looking into.

But barring that, your described implementation using text files seems workable.