Re: Database design, Keys and some other things
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 01 Oct 2005 21:20:30 GMT
Message-ID: <y4D%e.29649$1i.28023_at_pd7tw2no>
>>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?
Date: Sat, 01 Oct 2005 21:20:30 GMT
Message-ID: <y4D%e.29649$1i.28023_at_pd7tw2no>
dawn wrote:
> 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.
Is this a tautology?
> This excludes any data that might be used > exclusively by the database (e.g. hash codes).
p Received on Sat Oct 01 2005 - 23:20:30 CEST