pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ken Hill <ken@scottshill.com>
To: gry@ll.mit.edu
Cc: pgsql-sql@postgresql.org
Subject: Re: unique constraint instead of primary key?  what
Date: Wed, 08 Feb 2006 18:34:22 -0800
Message-ID: <1139452463.16438.8.camel@localhost.localdomain> (raw)
In-Reply-To: <20060208210455.5d6f5bf9.gry@ll.mit.edu>
References: <20060208210455.5d6f5bf9.gry@ll.mit.edu>

On Wed, 2006-02-08 at 21:04 -0500, george young wrote:

> [PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.1]
> I'm designing a completely new schema for my database.  A major
> criterion is that it facilitate ad-hoc queries via MS-access, excel and
> OpenOffice, presumably with ODBC.
> 
> My question regards the use of UNIQUE constraints instead of PRIMARY
> KEY's on some tables.  Both result in an index on the specified tuple
> of fields, so I presume query performance shouldn't be much different.
> 
> Using UNIQUE constraints seems to let me better match the natural
> structure of my data.  A 'run' contains a sequence of 'opsets'.
> Each opset contains a sequence of (a few) 'step's.
> 
>    run-foo
>       opset-1
>          step-1
>          step-2
>       opset-2
>          step-1
> 
> So the 'steps' table is logically indexed by (run, opset_num, step_num).
> But some opsets are not in runs, and some steps are not in opsets, so
> I would have step.run be null in some cases, likewise step.opset_num.
> 
> Null values mean I can't use these fields in a primary key, so I
> propose to use UNIQUE constraints instead.
> 
> What am I losing by not using PRIMARY KEYS?  Will ODBC clients have
> difficulty dealing nicely with the database?  Will the planner produce
> lousy query plans?  Will Edgar Codd haunt my dreams?
> 
> -- George Young
> 
> 

I think I can give you some insights about MS Access to help you. In MS
Access, you can specify a column as a "primary key"; which basically
means the column is indexed and must contain unique values (also, nulls
are not allowed). I have run into problems depending on columns being
"primary key" in MS Access in db apps that receive data in batch file
uploads from other sources (e.g., uploading 1,000+ records into a
table). 

Is sounds like your requirement to use MS Access for ad-hoc queries
means that you will have some users that want to access the database
with MS Access as a "front-end" client tool. If that is the situation,
then you don't need to worry about the structure of the table as MS
Access relies on ODBC for this. You may also want to communicate to the
end users that MS Access is not a client-server tool; in other words,
all of the records are transferred from the server to the client's box
and then the query is executed.

I hope that helps.

view thread (9+ messages)  latest in thread

Message-ID: <1139452463.16438.8.camel@localhost.localdomain>
Permalink:  ../1139452463.16438.8.camel@localhost.localdomain/
Also on:    postgresql.org/message-id/1139452463.16438.8.camel@localhost.localdomain

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: ken@scottshill.com, gry@ll.mit.edu
  Subject: Re: unique constraint instead of primary key?  what
  In-Reply-To: <1139452463.16438.8.camel@localhost.localdomain>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox