Обсуждение: Re: [QUESTIONS] Arrays (inserting and removing)

> OIDs are a bastardization of the relational model.  If you have to keep
> them, then do so, but their use should be SEVERELY discouraged.

Explain yourself, please.

In my opinion, I view the OID in the same way as I view the SERIAL datatype
in Informix.  It is usually a primary key field in a table.  On an insert,
the DBMS will increment the current serial-maximum (for that table) and insert
the new serial value into that field; thus creating a unique identifier.

There are differences between OID and SERIAL.  The main difference is that
the OID field (always called 'oid') is always present whereas a DB designer
explicitly creates 'id' fields (of SERIAL type).  Thus, postgresql treats
every table as an object (which is not always the case).

Is the SERIAL datatype part of the SQL-92 standard?  Does PostgreSQL plan
to support SERIAL in the future.  This would be an acceptable replacement
for the OID.

-Bryan Basham

On Thu, 15 Jan 1998, Bryan Basham wrote:

>
> > OIDs are a bastardization of the relational model.  If you have to keep
> > them, then do so, but their use should be SEVERELY discouraged.
>
> Explain yourself, please.
>
> In my opinion, I view the OID in the same way as I view the SERIAL datatype
> in Informix.  It is usually a primary key field in a table.  On an insert,
> the DBMS will increment the current serial-maximum (for that table) and insert
> the new serial value into that field; thus creating a unique identifier.
>
> There are differences between OID and SERIAL.  The main difference is that
> the OID field (always called 'oid') is always present whereas a DB designer
> explicitly creates 'id' fields (of SERIAL type).  Thus, postgresql treats
> every table as an object (which is not always the case).

    Major problem with OID: OIDs are sequenced across the database,
not the table.  ie. tableA inserts with OID #1, tableB inserts with OID
#2, tableA inserts next record with OID #3, tableC then gets #4, etc...

    And...# of OIDs is finite...so if you have a lot of tables with
alot of data in each...you run the risk of running out.

    In this sense, sequences are the better alternative, but again,
they are a newer feature to PostgreSQL then the code that I wrote using
OIDs

On Thu, 15 Jan 1998, The Hermit Hacker wrote:

>     Major problem with OID: OIDs are sequenced across the database,
> not the table.  ie. tableA inserts with OID #1, tableB inserts with OID
> #2, tableA inserts next record with OID #3, tableC then gets #4, etc...

in my oo world (i.e., systems i develop), i use oid's to determine the
type of object and due to the limitation of postgresql's oids, i use a
separate field for the system's oid - kinda redundant but gotta live with
it.  nonetheless, postgresql's oids can still be improved.

>     And...# of OIDs is finite...so if you have a lot of tables with
> alot of data in each...you run the risk of running out.

finitely limited :)

[---]
Neil D. Quiogue <neil@iphil.net>
IPhil Communications Network, Inc.
Other: neil@postgresql.org