Обсуждение: constraint via selection

Dear list, 

I have two simplified tables "country" and "location":

create table country (code char(2) primary key,name varchar(60)
);

create table location (id serial primary key,country char(2) references country(code),[...]
);

Location should have a foreign key to country.code, but for performance & 
ressource reasons it would be much better to have a copy of the country 
code in location.country rather than a foreign key:

create table location (id serial primary key,country char(2) check ...
);

What would the most efficient formulation of the "check" constraint be in 
this case?

Horst

> What would the most efficient formulation of the "check" constraint be
> in this case?

Sorry, I probably should reformulate my question into "is there a more 
effficient constraint than a foreign key constraint for this simple 
problem"?

Horst

I don't know much about this issue. but perhaps, since I assume the country codes are static, it would be faster if you
justchecked each individual value (especially if there are few of them) like so
 

CHECK code = 'no' OR code = 'de' OR code = 'se', etc.

I don't know.

Regards,

Aasmund.
On Sun, 18 Nov 2001 00:00:57 +1100, Horst Herb <hherb@malleenet.net.au> wrote:
> 
> Sorry, I probably should reformulate my question into "is there a more 
> effficient constraint than a foreign key constraint for this simple 
> problem"?
> 
> Horst
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org

Aasmund Midttun Godal

aasmund@godal.com - http://www.godal.com/
+47 40 45 20 46

On Sun, 18 Nov 2001, Horst Herb wrote:

> > What would the most efficient formulation of the "check" constraint be
> > in this case?
>
> Sorry, I probably should reformulate my question into "is there a more
> effficient constraint than a foreign key constraint for this simple
> problem"?

Hmm, it depends.  You probably can't manage it through check constraints
unless you knew the values (at which point you might not even the other
table) since I'm pretty sure we don't support check constraints with
subselects in them. It's possible that for your application you could
manage to make a trigger that beats the foreign key constraint and
do it that way.