--- Marc Compte <
mcompte@...> wrote:
> Hi,
>
> Ermm ... wasn't one of Codd's rules "Each and every datum (atomic value)
> in a relational data base is guaranteed to be logically accessible by
> resorting to a combination of table name, primary key value and column
> name."?
Yep.
> I find it surprising to see that "there's no need for a gid, from the
> database point of view" and that primary keys are only needed because
> "most applications want some way of identifying specific rows", as the
> very core definition of the relational model clearly identifies this as
> a crucial part of the model. Wanting to identify specific rows is not an
> application oddity, it's part of the very definition of the model.
I think you are confusing an automatically generated gid attribute with a
primary key. Sure, it could be a primary key, but there may well be others,
which may be data driven (single or composite).
Making the gid optional, simply allows the user to use a gid if appropriate, or
lets them use an alternative primary key. If the table already has a primary
key, there is indeed "no need for a gid".
Just like Postgres itself now has optional oids.
Making these fields optional does NOT make primary keys optional. (well, they
are, but the relational model is well & truly broken if you don't have one,
whether or not you actually define it as such. The data can have a viable
primary key, even if it is not specified as such in the schema)
Cheers,
Brent Wood
_______________________________________________
postgis-users mailing list
postgis-users@...
http://postgis.refractions.net/mailman/listinfo/postgis-users
