> On Mon, 03 Nov 2014 11:50:17 +0200 > Paul <de...@ukr.net> wrote: > > > > > Would be nice to have ability to store both key and payload in the > > > > index. (Let's call it index-only table) > > > > This could be a feature that sets some limitations on a table, > > > > like being unable to have more than one index or inefficient > > > > table scans, but it will also give some advantage in special > > > > cases like mine. > > > > > > What you're describing sounds very much to me like a SQLite table. > > > See http://www.sqlite.org/fileformat2.html, section 1.5, the > > > reference to "index b-tree". > > > > So, to be clear, WITHOUT ROWID table will have it's PRIMARY KEY > > as a replacement for ROWID and table itself is an index? > > Yes, approximately. http://www.sqlite.org/withoutrowid.html says: > > > CREATE TABLE IF NOT EXISTS wordcount( > > word TEXT PRIMARY KEY, > > cnt INTEGER > > ) WITHOUT ROWID; > > > > In this latter table, there is only a single B-Tree which uses the > > "word" column as its key and the "cnt" column as its data. > > That is, the table is stored as a B-tree with the declared primary key > as the B-tree key. > > I wouldn't say, "the table is an index". I reserve the word "index" in > this sense to mean "something that speeds up searching in something > else", and in this case there's no "else". > > The table is stored on disk as a tree. A tree can be used as an index, > and an index may be implemented as a tree. But not every tree is an > index. > > HTH. > > --jkl
Thank you for your answer, James! Regards, Paul _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
