Re: [sqlite] 5000 tables with 3000 records vs 1 table with 15000000records
On 22 Aug 2010, at 6:34pm, ve3meo wrote: > A master database with pointers to > each of the stock databases, ATTACH as many as you want to view at one time, > maybe combine data into temporary table(s), create and drop indexes on the > fly thus keeping storage at a minimum. I was going to suggest something else. If you think you might ever want one application to report on two stocks in the same run, then use one huge file with all the data in. If that makes no sense, and you would never compare/total/merge stocks on the same display, then use separate files. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 5000 tables with 3000 records vs 1 table with 15000000records
"Mike Zang" ... > In fact, the file is stock data and one file is for one stock, so they are > all in the same format. > > Then, in most case, only one stock should be selected. > Then, from a 'disk' operating system and memory management perspective, wouldn't one file per stock continue to be faster and more efficient than having all the stocks in one big file? A master database with pointers to each of the stock databases, ATTACH as many as you want to view at one time, maybe combine data into temporary table(s), create and drop indexes on the fly thus keeping storage at a minimum. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
