Re: [GENERAL] using ID as a key

Поиск
Список
Период
Сортировка
От Marten Feldtmann
Тема Re: [GENERAL] using ID as a key
Дата
Msg-id 200002071717.SAA03101@feki.toppoint.de
обсуждение исходный текст
Ответ на Re: [GENERAL] using ID as a key  (Sevo Stille <sevo@ip23.net>)
Список pgsql-general
> davidb@vectormath.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

 The are algorithm out there which handles this problem very well and
perhaps much better than a database can do and they define a key in a
complete portable way and it needs only some queries to the database
at the beginning of your application and for further key generation
the's no further communication needed in a multi-user environment.

 The algortihm are available, the software is available and there's
no need for the database to offer this special feature ... but of
course it's another feature ("marketing") and it's more handy to use
if you do many "manual" sql execution rather then using this
database in an application environement.

 I've described such an algorithm on a pgsql list ("High-low algorithm")
some weeks ago. Papers are out in the internet - they are mostly described
in papers which talk about "object - rdbms" mapping.

 Marten






В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: [GENERAL] using ID as a key
Следующее
От: Marten Feldtmann
Дата:
Сообщение: Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL