When is core data appropriate?

What are you using for the back end? Is it a Mac?

There really isn't an issue in terms of the quantity of data, maybe your hosts internet connection bandwidth, but you shouldn't have an issue otherwise.

Not sure what core data does for you, someone else would have to answer that.

Are you writing objects? Does the iPhone app need real time access to the DB or is the DB used for statistics?

You can cache data on the back end and put it into a queue. Just have a separate thread read the queue and write it to disk/database if you want to.

If you want to write directly to a DB, you need to batch the rows (multiple rows / commit). You would probably have to do some work to get the DB up to speed.

If your not depending on live access, one strategy I've seen is to write to a flat file in CSV format and cut it off at say 50MB. Each time the limit is reached, create a new file with an incrementing number in the filename ie., myfile0001.csv, myfile0002.csv, etc.. Then just create some scripts that check for the next file in sequence and load it using the normal DB utilities.

This saves you a lot of effort in building the DB interaction.

 

From a real world perspective, I would never write objects to a file.

The problem is that if you have a problem, you need to build a set of tools to analyze and search the data. Any time I build a new system, I aways build a text file format for the output.

In the line of work I do most (Financial Services), we always write to file in addition to writing to the database. It allows portability and backup so you can bring data into either QA or Development and be able to re-create/re-produce things fairly quickly. Serialized objects sound cool, but I've never found it to be a good solution. It's easier to pop data into an editor or be able to grep the data searching for something specific.

Think about how you will need the data in the future, not how you can take advantage of built-in features.

As far as bandwidth, host providers are pretty flexible, but for what your doing, you may need to think about how to deal with regional server farms, etc. Make the infrastructure flexible, maybe take advantage of the gps capability and figure out which regional hosting to send the data to.

Are you going to open the product up to different countries? If so, are you going to host in those countries? Two messages per second per iPhone might be a bit much to ship half way around the world (protocol timeouts, etc).

Lot's of basic decisions to make first... The rest will follow.