[go: up one dir, main page]

Postgres, DB design, and object IDs (of any ilk)

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?

Responses Browse pgsql-general by date
  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