Re: Database design, Keys and some other things

mAsterdam wrote:
> David Cressey wrote:
> > mAsterdam wrote:
> >
> >>There is an important difference. Unless we are talking about
> >>that specific "*some*" database, the VIN is /not/ a surrogate key in
> >>the database at hand.
> >
> > Agreed. This is an important difference.
> >
> > Perhaps the difference is between "externally supplied data" and "internally
> > generated data". In a typical personnel system, new employee ids are
> > assigned by the HR department, and they are responsible, ultimately, for
> > avoiding duplicate assignments. The IT department ultimately is only a
> > custodian of data that the HR department "owns". Of course, the IT
> > department codes duplicate rejection somewhere into their systems, so as to
> > help HR discover their errors in a timely fashion.
> >
> > So, when we have a "surrogate key in the database at hand" (or, if you can
> > accept it, "in the system at hand") what we have is data that is "owned" by
> > the system itself, rather than merely kept in custody by the system for its
> > owners.
>
> Makes sense to me. Along these lines:
> Exposing system owned data to users should
> be done only when necessary:
> error codes/messages, hm... what more?

I favor access to all data & metadata for any users of the database who have such privileges. This excludes any data that might be used exclusively by the database (e.g. hash codes). The database should have no other "hestitation" in providing any collected data or metadata within the constraints of security. Why do otherwise? --dawn Received on Sat Oct 01 2005 - 22:45:13 CEST