On 5 Oct 2009, at 8:02am, Keith Roberts wrote: > On Sun, 4 Oct 2009, Simon Slavin wrote: > >> But note that the fields of the row are stored in (more or less) a >> list. So accessing the 20th column takes twice (-ish) as long as >> accessing the 10th column. If you make a table with 100 columns it >> can take a long time to access the 100th column. > > Could this not be implemented as a B-tree search algo as > well? Maybe something like a FAT (RAT?) index stuck > on the front of the table rows?
Certainly could. But it would be slower and a waste of filespace for the vast majority of databases out there. However, it's generally felt that any solution which involves a table with 100 columns shows that you didn't understand the question. You should be able to hold all the columns of a table in your mind at once. If you notice that you're numbering your columns, then you're probably better off making those numbers a key column. Otherwise you might consider reorganising the data as a properly list. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
