SQLite data storage

[Alan Stenhouse]

Hi Chris

While not a SQLite guru, I have used it on and off at various times and would probably recommend just having it all in 1 table. Any read-only queries will just return you a record set which you can put in a container and do anything with. SQLite is quick, you can add indices and custom views. Think it'd keep your management much more straightforward than multiple tables. But just my 2c... ;-)

cheers

Alan

> 
> I need some advice/pointers on how best to store some static "read-only" data in a SQLite database. We're talking potentially thousands of records. I've been given an Excel spreadsheet with 24 sheets containing data to import. There are about 12 fields/columns. The data is separated into 24 sheets, but it could potentially all reside in one table in the database (fields are the same on each sheet). The question is, should I do that? Will SQLite bog down after a while? This new app we're working on will need constant access to this database, probably via several open record sets at once. I'm just trying to figure out if it would be best to store everything in one large table, or to split each sheet of data into its own table. Would that be more efficient? Or would it be even better to have each sheet in its own file? Also, are there specific settings/properties I should set on the db to help keep performance as optimal as possible?
> 
> Just brainstorming here. Would love to hear opinions, especially if someone out there is a SQLite guru. :-)
> 
> Thanks,
> Chris
> 
--
Alan Stenhouse
alanstenhouse at hotmail.com

Check out our apps on the App Store:

BeatSpeak - the multilingual talking metronome;
EV-Point - Find your nearest Electric Vehicle Recharge Station.