Re: Database design, Keys and some other things
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 01 Oct 2005 23:27:42 +0200
Message-ID: <433efe99$0$11076$e4fe514c_at_news.xs4all.nl>
>>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 23:27:42 +0200
Message-ID: <433efe99$0$11076$e4fe514c_at_news.xs4all.nl>
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. 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
When would you show a surrogate keys?
Only when necessary. A lot of things get numbers so it is easy
/for people/ to refer to them:
complaints, tickets, orders, invoices, legal cases, bugtracks.
But numbers assigned only to make the system able to track
something should not bother users, IMO.
Did you know that one of the references to your message is
<1127614484.101580.227050_at_z14g2000cwz.googlegroups.com> ?
Metadata has users.
I agree that all (well allmost all) metadata should be
as readily accessible as possible - when necessary.
Received on Sat Oct 01 2005 - 23:27:42 CEST