On Thu, 23 Jan 2003, Ross J. Reedstrom wrote: > So in the longer term, we need to provide a replacement. Arguably, the > primary key for a table is the right replacement, but we don't _require_ > a pkey, so what to do in cases where this isn't one?
You're stuck. SQL breaks with relational theory in this way; tables need not have candidate keys, and thus you can have duplicate rows in a table. (I.e., mathamatically, a table is not a set, it's a bag.) The implications of this start to go on and on, but let's not get into that here. > Also, the pkey can be _any_ column(s), of _any_ type, which could be > inconvenient for returning as the result of an insert, for example > (imagine a text field as pkey, with a _huge_ block of text just > written into it ...) Well, this could be worked around to some extent, with some hackery. But in the end I reckon it's much easier just to have the object system force you to declare specific a specific object-ID column, if that's what it takes. So long as you've got a candidate key, even if it's not the primary key, you're fine. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
