> 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
rtroy@ScienceTools.com, http://ScienceTools.com/