Re: oid's in views.

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: Dado Feigenblatt <dado(at)wildbrain(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: oid's in views.
Date: 2001-10-24 15:28:46
Message-ID: web-491310@davinci.ethosmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Hey, Dado,

> Hi Josh!
> Once you have your usq, how do you get more info about that row?
> How do you know which table it came from?

Well, if you have to go at it from that angle (hey, I have this USQ,
where did it come from) then you're in trouble. However, I never use it
that way. Let me give you an example of USQ use:

Modifications table

TABLE candidates
usq INT4 DEFAULT NEXTVAL ('universal_sq'),
first_name VARCHAR NULL,
etc.

TABLE orders
usq INT4 DEFAULT NEXTVAL ('universal_sq'),
client_usq INT4 NOT NULL REFERENCES clients(usq),
etc.

TABLE mod_data
ref_usq INT4 NOT NULL PRIMARY KEY,
entry_date DATETIME NOT NULL,
entry_user INT4 NOT NULL references users(usq),
mod_date DATETIME NOT NULL,
mod_user INT4 NOT NULL references users(usq)

Thus I effectively have a One-to-One relationship between all of the
tables posessing USQs and the mod_data table. This means I can use one
function to update this timestamp information, regardless of table,
whenever a record is inserted or updated.

When I'm retrieving modification information, I never start with the
mod_data table. To do so would be asking the question, "What records,
in any table, were modified by Josh on Decemebr 12th?" which really
isn't useful and would be very difficult (but possible) to query.

Instead, the question I'm usually asking is, "When and by who was the
current record on the screen modified?" Which means that I am
retrieving a single, unique, row from mod_data (SELECT * FROM mod_data
WHERE ref_usq = 451).

This whole scheme, which has been very convenient for me, would not have
been possible without a good way of insuring USQ uniqueness between
tables, which, thankfully, our core team was foresighted enough to
supply. Unfortunately, that does mean that this solution is not
portable to other RDBMSs, but as PostgreSQL grows in market share,
that's less of a concern.

-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh(at)agliodbs(dot)com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco

Attachment Content-Type Size
unknown_filename text/plain 2 bytes
unknown_filename text/plain 2 bytes
unknown_filename text/plain 2 bytes

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2001-10-24 15:31:51 Re: GUID in postgres
Previous Message guard 2001-10-24 14:56:06 Lock full database