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 [email protected] Check out our apps on the App Store: BeatSpeak - the multilingual talking metronome; EV-Point - Find your nearest Electric Vehicle Recharge Station. _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
