Am I babying the platform/hardware?

I can't tell if I'm being respectful and courteous to the user or if I'm unnecessarily handicapping the utility of my app in the name of treating the ph开发者_StackOverflowone like a china doll.

I have a successful app in the Android Market. One main functionality is that it records sports stats from a game the user is scoring. The current level of detail is fairly basic: a row for each player and a field for each basic stat. However, I could conceivably dramatically increase the detail and level of usefulness of the app if I recorded additional information, blowing this up to numerous relational tables and conceivably thousands upon thousands of records.

My question is, is this a responsible thing to do? Up to this point, I've shied away from it, thinking that "it's just a phone" and "it's just SQLite", but I've never really looked at whether that's a legitimate reason to hold back on doing things that I wouldn't give a second thought to doing on a web or desktop app.

So with that, how much data (very quantifiable, I know) is it reasonable to expect a phone app to do in regards to storing and sifting through database records?

EDIT: To be clear, I'm not simply talking about adding more fields as I know the impact of that is trivial. I'm talking about going from the level of detail of "This player has 5 singles and 3 homers" to storing information about each pitch that comprised each at-bat that lead to 5 singles and three homers. Obviously this will call for additional tables and conceivably a great many records.

For my masters thesis project at CMU, I worte an Android app that collected roughly 300mb (2.5 Million rows in the main table) of data during one day in sqlite. It drained the battery of the phone in about 10 hours and CPU utilization was at around 50%, but nothing of that had a lot to do with data. We were doing online learning on physiological data coming in over bluetooth with 72Hz. With the math intensive parts cut out, the phone was quite fine and useabel while the service was running. And the 10 hours were mostly due to bluetooth running continously. Without bluetooth, we got about 16-18 hours of continous uptime. Which I don't even get these days on the HTC Desire.

AND THIS WAS ON A G1

I think you're fine if you stay in the Megabytes or maybe low 10's of megabytes. As long as you have a a good design and don't do expensive querys in the main thread. SQLite handles well formed queries quite well, and dumping data into it is REALLY fast.

[edit:] just thought of something: Why don't you provide a second version of your app with the additional fields? More calculation obviously means a bit more battery drain, so I would give users some kind of choice. But my intution is that the performance hog won't really be noticeable.

Sounds like SQLite will do just fine for what you need. I wouldn't hesitate to push it's limits. It's a very well implemented product and should be able to handle what you describe. If you get to the point where your application is handling larger volumes of data (more than 100-200MB), you might want to consider Berkeley DB. Berkeley DB supports the SQLite3 API and provides additional data management capabilities that provide better performance, scalability and reliability than native SQLite, especially when dealing with larger data sets. - Dave