Re: Database design, Keys and some other things

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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> ?

Metadata has users.
I agree that all (well allmost all) metadata should be
as readily accessible as possible - when necessary.
.

Relevant Pages

  • Re: Another view on analysis and ER
    ... Broken database. ... If you're issuing assignments, that is, deletes and inserts, then ... By not using the VIN, ... since there is a 1:1 correspondence between that which is ...
    (comp.databases.theory)
  • Re: A real world example
    ... use a temporal attribute to make the tuples in the database instance ... preceding a change correspond to tuples in the database instance ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)
  • Re: Database design, Keys and some other things
    ... In a typical personnel system, new employee ids are assigned by the HR department, and they are responsible, ultimately, for avoiding duplicate assignments. ... Of course, the IT department codes duplicate rejection somewhere into their systems, so as to help HR discover their errors in a timely fashion. ... Exposing system owned data to users should be done only when necessary: error codes/messages, ... I favor access to all data & metadata for any users of the database who ...
    (comp.databases.theory)
  • Re: A real world example
    ... use a temporal attribute to make the tuples in the database instance ... I was referring to why tuples between relation-values cannot correspond ... issuing a series of assignments introduces its own problems. ... including those that are not included in the propositions about it. ...
    (comp.databases.theory)
  • Re: Help - new user cant log in
    ... did miss the group assignments. ... > database permissions to use the database. ... > belong to. ...
    (microsoft.public.access.security)