On Mon, Nov 18, 2013 at 5:45 PM, Nico Williams <n...@cryptonector.com>wrote:
> Obviously a B-Tree-based table will need *some* key, but it won't need > that key to be UNIQUE. > Yeah it does. Every storage system has a unique key, be it an address in memory or a filename and offset on disk. There must be some way to distinguish between two record. Two records with the same key are indistinguishable from one another and are hence the same record. The question is whether or not the unique identifier is exposed to the application. SQLite allows the unique identifier to be a PRIMARY KEY ... WITHOUT ROWID. Or it allows it to be the rowid. You get to choose. But every table has to have one or the other. You can argue that it is theoretically possible to create a table where the key is something other than PRIMARY KEY or rowid (perhaps it is the filename+offset suggested above) that is simply not exposed to the application layer. Yes, that is theoretically possible. But SQLite does not do that and I do not see any reason to add the capability. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
