Hi Nico, thanks for the discussion - although this thread is dangerously close to becoming a stale debate rather than a helpful
forum discussion.
In this light, I will try to be brief and then fight the urge to reply again.
You still seem to try and sell the usability of non-unique tables to me, I'm with you on that, no need to keep pushing it. What I'm
saying is even though you can conjur up valid use-cases, I am not convinced it merrits the changeover for SQLite.
A B-Tree quite clearly imposes no need for uniqueness; the uniqueness requirement in SQLite3's WITHOUT ROWID almost certainly
derives from PRIMARY KEY being a convenient syntactic source of columns for the primary index. There are alternatives to
overloading existing syntax; MySQL has a suitable syntax, and even without it there are alternatives. Overloading syntax is not
always free... Nico --
MySQL use internal row indexers for both INNO and ISAM table types (there are others of which I do not know the workings, though),
the only difference is that A - they are not BTrees, which SQLite chose to use, and B - there is no way to access the internal row
pointers in MySQL through SQL statements and the only reason it's accessible in SQLite is because it mimics a normal PKey - for the
sole reason that it essentially is one.
Again, I might be wrong about this and rowids may have been designed in lieu of internal pointers specifically to be used by people
for some reason or the other. A Dev with more insight weighing in on this might be a more trustworthy source.
Either way, for whatever reason(s) rowids were used, now the PKey is chosen to replace rowid since for the most part, tables that
can perform well sans said rowid are typically those that already have PKeys and if we drop the rowid, SQLite can STILL directly
dereference any row inside a table because it still has a unique Key to go on. I very much doubt your contention that it was merely
a "convenient source of columns" - in fact, I would like to postulate that it would be impossible, as it stands now, for SQLite to
directly access table rows missing both a Primary key and rowid - not merely inconvenient.... but I could be wrong.
Cheers!
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
