From: | Jay Bloodworth <jay(at)dokodiner(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | SERIAL vs. OIDs |
Date: | 1999-08-29 22:52:11 |
Message-ID: | 37C9B99B.4C68BFBA@dokodiner.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Seeking informed opinion on what is better to use as a unique row id for
linking tables together in a normalized database, a SERIAL field or the
pgsql OID. This is for an intranet application with a small user base,
but I'd like to make it robust and scalable where it is easy to do so.
My conclusions so far:
OIDs:
Pros:
* They're already there; save a couple bytes per row
* Specific method to retrieve after INSERT (maybe faster than SELECT
on the sequence)
Cons:
* Not serial by table; hard to build linked table 'by hand'
* not pure SQL
SERIAL:
Pros:
* Based on fairly vanilla SQL
* Easier to reproduce all or part of a db on a dump/restore
Cons:
* Performance?
* Extra id field redundant
I'm sure I'm missing something, and I'm not entirely sure how to weight
the points I've got. Advice appreciated.
Please CC me. I subscribed to the digest.
Jay
From | Date | Subject | |
---|---|---|---|
Next Message | Jay Bloodworth | 1999-08-29 23:08:45 | OID vs SERIAL |
Previous Message | Dimitri | 1999-08-28 22:47:26 | Re: [GENERAL] Hardware optimising |