From: | Kenneth Tilton <kentilton(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Postgres, DB design, and object IDs (of any ilk) |
Date: | 2009-05-21 16:35:49 |
Message-ID: | 4A1582E5.6060400@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Just looking for postgres "best practices" input from the veterans:
If the primary key of the customer table is cust_short_name and my DB
reflects also customer departments, I can link a customer to its
departments one of three ways:
1. The department table has a cust_short_name column and makes that the
first segment of its primary_key;
2. I use OIDs and link back to the customer's row with the row's OID;
3. I give the customer a cust_serial_id column and make it SERIAL and
give the dept table a column called cust_serial_id.
I know serial IDs are preferred to OIDs so let's forget #2.
With #1, where we have a three or more level identifying hierarchy I end
up repeating two or more primary keys in building up the primary key of
the lower levels. Not the end of the world, but my last DB was built in
an OODB so I got uses to having object identity and am tempted to use
serial_ids for same under postgres.
Bad idea?
From | Date | Subject | |
---|---|---|---|
Next Message | Keith D. Evans | 2009-05-21 16:41:05 | running postgresql on a private machine accessing it from public web pages |
Previous Message | Tom Lane | 2009-05-21 14:30:35 | Re: [GENERAL] compilation test fails |