On Mon, Aug 8, 2016 at 5:59 PM, Craig Boucher <craig@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
