From: | Sevo Stille <sevo(at)ip23(dot)net> |
---|---|
To: | davidb(at)vectormath(dot)com |
Cc: | pgsql-general(at)postgreSQL(dot)org |
Subject: | Re: [GENERAL] using ID as a key |
Date: | 2000-02-07 12:27:43 |
Message-ID: | 389EBA3F.D5F54037@ip23.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
davidb(at)vectormath(dot)com wrote:
>
> Hi Sheila,
>
> For general database design considerations (not specific to Postgres) I
> disagree with the others on the use of serials and sequences. These
> things never migrate well from platform to platform, they often break, and
> dealing with them is a nightmare if you ever have to do any bulk data
> copying.
> ID generation ought to be handled programmatically.
At the server? This is what OIDs do - alas, these are even less portable
than serials and sequences. At the client interface? Nice, as long as
you have a single user database. In a multiuser environment, generating
and maintaining a unique ID externally to the database is close to
impossible. Simply incrementing the highest available ID from the
database by one is error prone, even if you catch duplicate insertions
by making the ID field UNIQUE and incrementing the ID in a loop until
you succeed - a slow client in a heavily updated database might
permanently fail to insert his record before the generated ID is used by
some other, faster client. And generating unique IDs based on an
database-independent would require some synchronized mechanism for ID
generation, adding dependency on the ID source to dependency on the
database.
Sevo
--
Sevo Stille
sevo(at)ip23(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Karl DeBisschop | 2000-02-07 14:31:54 | Re: [GENERAL] using ID as a key(REPOST) |
Previous Message | postgres | 2000-02-07 10:56:04 | RE: [GENERAL] Grant problems |