On Sun, Sep 12, 2010 at 2:15 AM, Stephen Oberholtzer < oliverkloz...@gmail.com> wrote:
> > Stephen, are you telling that is' smaller in any situation? When I > mentioned > > the trigger in case of fast reading of rowid/id, I thought that in this > case > > there can be a separated table with sing field id (rowid) that should > change > > its contents synchronously to the main table that contains all data. I > > suppose in this case the two variants (index vs trigger) is on par in > terms > > of the size or am I wrong? > > > > Max > > Underneath the surface, an index is just a mini-table that contains > the indexed columns, plus the rowid, and is stored in sort order. > An index will always contain the indexed columns, plus the rowid. > Since their is no way to have MORE columns in an index than in the > table itself, there is no way for an index to be bigger than its > table. > > Thanks for your detailed description, my initial post already contained the reference to the fact that the index is smaller than the table itself, that's why I already used this method. I just tried to ask you whether you see any reason for a different table containing interested fields and linked to the main table with the trigger to be bigger than the index created on the same fields. Or (if sizes are similar) the trigger has some other disadvantages... Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
