On Mon, Aug 8, 2016 at 5:59 PM, Craig Boucher <craig@wesvic.com>
wrote:
> Thanks Kevin for your response. I've Googled and debated natural
> vs surrogate keys and I just find surrogate keys easier to work
> with (maybe I'm just being lazy). It just seems that a
> description or name is most often the natural key. I just can't
> see, In my case, using a department description as part of the
> primary key in the department table and having it repeated in
> millions of rows.
I agree that would not make sense, but most organizations I've
worked with already have user-visible mnemonic or numeric codes for
such things. Those make great keys, or columns within multi-column
keys.
Anyway, the synthetic key discussion was peripheral to my main
point, which was that you were looking at moving from something
that looked like 2nd or 3rd normal form down to 1st normal form,
which will open you up to whole new classes of data integrity
problems. I strongly recommend you don't do that. It looked like
the reason was to try to introduce more meaning into the key, which
is why I ventured into the synthetic key discussion in spite of it
being such an unfortunate trigger for rehashing old flame-wars.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
