Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux