Using a database to save player/team data in a sports sim android app

Question

I'm trying to wrap my head around the most efficient way to implement a database in a sports sim game that I'm working on for android.

Currently in the app, the user can pick a team to coach, sim through their schedule, change their lineup, and look up their players' stats as the season goes along. There's no save feature yet so I thought saving all the player stats, team rosters, etc could be implemented with a database.

Right now when a user picks a team, I have a league object that generates all the team objects that in turn have player objects. I'm trying to wrap my head around all of the things I'll have to change in my app with a database. I guess when I generate the league, I'd be doing a lot of writing to the database (teams, players, etc) and then when the user quits and starts up the app again, I'd have to read all that data in and re-create all of the league, team, and player objects? Does that sound like the right way to go about it? I feel like I'm kind of rambling but I don't have much experience at all with using databases with an extremely object oriented app like this.

Answer 1

Unless you're listing all the teams in all sports all over the world, I think sqlite is suitable to your case.

It's easy to use, debuggable, and lets you prepare/ edit your DB with tools like SQLite spy, SQLite Database browser or such. Each tool has its good and bad/missing feature, but you'll find great stuff to design and later prepare SQLiteDatabase for your starting database.

If you already wrote objects, you could both decouple them with a DTO approach to persist teams/rosters/etc., or choose to directly make them "persisteable" writing proper methods (ie. refresh(), delete(), etc.) inside classes you already have, SQLiteQueryBuilder is very useful there.

As a 'pure thumb' order of magnitude, an UPDATE execution of some (3-4) String columns on an average sized (5-10k rows) table takes milliseconds (say 5-30ms). For reading, an index based SELECT * returns the SQLiteCursor object almost immediately (<5msec.), so that putting pure DML commands can be done even inside Activities' onCreate() methods. For "long operations" you mentioned, AsynchTask along with proper dialog messages can make the wait less boring and inform the user promptly.

Some limitations could derive from heavy concurrent DB access or later DDL changes (ie. you can't add a FK, you have to drop & recreate table) but the performance on modern devices are great and the DB file is portable .

Last not least, the documentation is good and many examples are available