Am I coming up with a platform / equipment?

Question

I can’t say whether I respect and are kind to the user, or if I unnecessarily find it difficult to use the utility of my application in the name of handling the phone, like a porcelain doll.

I have a successful application in the Android Market. One of the main functions is that it records sports statistics from the game, which the user scores. The current level of detail is pretty simple: a line for each player and a field for each base stat. However, I could, apparently, significantly increase the details and usefulness of the application if I wrote down additional information by blowing it into many relational tables and, possibly, thousands and thousands of records.

My question is: is this a responsible thing? Until now, I have shied away from this, thinking that “it's just a phone” and “it's just SQLite,” but I never looked to see if this is a legitimate reason to hold back on what I would do. “Don't think about doing it.” in a web or desktop application.

So, how much data (very quantitative, I know), is it reasonable to expect what the phone app will do in relation to storing and sifting records in the database?

EDIT: To be clear, I'm not just talking about adding more fields, as I know that the effect of this is trivial. I'm talking about moving from the level of detail "This player has 5 singles and 3 homers" to store information about each pitch, which consisted of each on a bat, which led to 5 singles and three homers. Obviously, this will require additional tables and possibly a large number of records.

Answer 1

For my graduation project in CMU, I was looking for an Android application that collected about 300 mb (2.5 million rows in the main table) of data in one day in sqlite. He drained the phone’s battery in about 10 hours, and the processor load was about 50%, but none of this had much to do with data. We conducted online training on physiological data coming through Bluetooth with a frequency of 72 Hz. When nodes with mathematical intensity were cut out, the phone was pretty good and applicable when the service was working. And 10 hours was mainly due to the smooth operation of bluetooth. Without bluetooth, we got about 16-18 hours of continuous uptime. Which I don’t even get these days on HTC Desire.

AND IT WAS ON G1

I think that everything is in order if you stay in megabytes or maybe 10 megabytes. So far you have a good design and do not make expensive requests in the main thread. SQLite handles well-formed queries well, and dumping data in it is REALLY fast.

[edit:] just thought something: why don't you provide a second version of your application with extra fields? More computing obviously means a bit more battery drain, so I would give users some choice. But my intuition is that pig-performance will not be noticeable.

Answer 2

SQLite seems to do just fine with what you need. I would not be shy to push him. This is a very well implemented product and should be able to process what you describe. If you get to the point that your application is processing large amounts of data (over 100-200 MB), you can 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 working with large datasets. - Dave