On Tue, Nov 19, 2013 at 6:35 AM, RSmith <rsm...@rsweb.co.za> wrote: > I also do not think (or imagine) that unique constraints "ought" to be > required - I am saying that in the case of SQLite or any mainstream RDBMS it > becomes necessary to have some unique reference to single out a row should > you wish to adjust it somehow (often, adjustment are not required, such as
Data which is apparently non-sensical to you can nonetheless be used in SQL queries and data modification statements that are meaningful to me. In all the cases I care about such data exist only ephemerally or not at all, but the cases where they exist ephemerally are important to me. In the ephemeral dups case I only need to be able to count duplicate rows, which is quite obviously trivial to do. This case is where I'm implementing application-defined uniqueness constraints that are substantially different from standard SQL uniqueness (more on this some other time) or where I'm implementing deferred uniqueness constraints. Deferred constraint checking is a valuable feature (evidence: SQLite3 added deferred FK enforcement). > for logs), and that (because of that) it is good that SQLite decided to have > rowids, if a little archaic. It's even better with the new optimisation > being possible, and certainly to keep all admin things working as it should, > I do not think it should drop the requirement. The case where the application needs either deferred uniqueness constraints handling or application-defined uniqueness constraints that are not [easily] expressible in SQL, but where the application uses SQL under the covers, is very much a real-world case. In that case I really need to have the RDBMS impose no unique constraints. 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 -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
