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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
