> David Fetter wrote: > > On Fri, Apr 06, 2007 at 09:22:55AM -0700, Joshua D. Drake wrote: > > > >>> The people that use it are the people stuck by dogmatic rules about > >>> "every table must have a primary key" or "every logical constraint > >>> must be protected by a database constraint". Ie, database shops run > >>> by the CYA principle. > >> Or ones that actually believe that every table where possible should > >> have a primary key. > >> > >> There are very, very few instances in good design where a table does > >> not have a primary key. > >> > >> It has nothing to do with CYA. > > > > That depends on what you mean by CYA. If you mean, "taking a > > precaution just so you can show it's not your fault when the mature > > hits the fan," I agree. If you mean, "taking a precaution that will > > actually prevent a problem from occurring in the first place," it > > definitely does. > > Heh, fair enough. When I think of CYA, I think of the former. > > Joshua D. Drake
...I was thinking the point was more on "primary key" as in syntax, as opposed to a table that has a/an attribute(s) that is acknowledged by DML coders as the appropriate way to use the stored data. That is, I may very well _not_ want the overhead of an index of any kind, forced uniqueness, etc, but might also well think of a given attribute as the primary key. Use of constraints in lieu of "primary key" come to mind... 'Course, maybe I missed the point! -smile- 'Nother thought: CYA _can_ have odeous performance costs if over-implemented. It's a matter of using actual use-cases - or observed behavior - to taylor the CYA solution to fit the need without undue overhead. Rgds, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
