This is just some commentary--not really a question.

Last month I decided to take a beginning "relational
database" class offered thru my employer (a U.S. state) at
no cost to me. Of course, in reality, it was a class on
Microsoft Access, with no mention that there was any other
DBMS on the face of Earth, but that seems to be the template
for classes in any type of computer software these days. The
class was conducted by an outside company, contracted thru
the state.

What really struck me as interesting was when the instructor
was demonstrating how to create a new table. She made the
"key" field a field which contained data that users would
need to see and work with. When I mentioned that it was my
understanding that key fields should not have any meaning
outside relating a record in one table to a record in
another table(s), she said she had no idea why anyone would
ever think that.

I just thought this might be interesting to folks here....

--
croy

On Thu, 26 Aug 2010 18:10:50 +0800, "Allen Browne"
<(E-Mail Removed)> wrote:

>Okay, so you want to weigh in on the on-going debate about whether you ought
>to use a surrogate key, even in cases where there is a perfectly suitable,
>unique, brief, natural key available (e.g. in a category lookup table)?
>
>If you search, I'm sure you'll benefit from reading both sides of the debate
>that has raged back and forth over the years.

Not long after making my OP in this thread, I was thinking
that I was probably just wasting bandwidth. Now I'm glad I
did. I was totally unaware that experienced data mongers
were straddling this issue. Thanks for clueing me in!

--
croy

On Tue, 31 Aug 2010 20:17:21 +0800, "Allen Browne"
<(E-Mail Removed)> wrote:

>Okay, Croy
>
>FWIW, I've tried various approaches over the years. These days I use the
>natural key for many little lookup tables, but not for any of my main tables
>where I expect thousands of records.

FWIW?! Learning what *you* do "these days" (what with your
talent and experience), is worth a *lot*!

Thanks!

--
croy