Re: referential integrity and defaults, DB design or trick

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: referential integrity and defaults, DB design or trick
Date: 2007-12-22 16:12:12
Message-ID: 20071222171212.61815c62@webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 21 Dec 2007 08:19:08 +0000
Richard Huxton <dev(at)archonet(dot)com> wrote:

> Ivan Sergio Borgonovo wrote:
> > The default property (that is actually made by several fields) in
> > my case is not completely homogeneous with the others, because it
> > has a double meaning.
> > It is cleaner to split the meanings and the data.
>
> It usually is. A lot of the design decisions you can regret a year
> or two down the line are from trying to use one value for two
> purposes.

Unfortunately it looked a nearly perfect solution till I didn't
discover there is some overlap of properties definitions.
One of the column of a default property is written somewhere else,
while a "not default" property has its own or doesn't have it at all.

I can't see any way to write an "on update cascade" somewhere in your
proposed schema.

Unfortunately I'm writing a plug-in and I've no complete control over
the schema.
I can't separate that column, put it in another table etc...

Decoupling the system as much as making all the angels of programming
sing in chorus, is going to make the design less maintainable than a
little hack.

/*
sort of...
*/

CREATE TABLE users (
uid serial primary key,
email varchar(64) unique -- I'can't move this away, not my table!
);

CREATE TABLE properties (
pid serial,
name text,
email varchar(64), -- but not default proprieties have their own
PRIMARY KEY (pid)
);
CREATE TABLE user_default_property (
uid int NOT NULL REFERENCES users,
pid int NOT NULL REFERENCES properties,
PRIMARY KEY (uid)
);
CREATE TABLE user_property_choices (
uid int NOT NULL REFERENCES users,
pid int NOT NULL REFERENCES properties
PRIMARY KEY (uid)
);

At this moment the best solution I can think of is hiding this behind
a function.

CREATE TABLE users (
uid serial primary key,
email varchar(64) unique -- I'can't move this away, not my table!
);

CREATE TABLE properties (
pid serial primary key,
name varchar(64),
email varchar(64),
otherstuff text,
);

create table user_property_choices (
cid serial primary key,
uid int NOT NULL REFERENCES users,
assigned boolean,
pid int NULL REFERENCES properties
);

if assigned=true -> if pid=null use default
-> if pid!=null use pid
if assigned=false -> not yet assigned

better than using "usedefault" system since anyway there will be
something to pick up and at least I won't have to deal with
exceptions.

Thanks again.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Broersma Jr 2007-12-22 16:38:33 Re: Requirements for Constraint Trigger's Function
Previous Message Michael Glaesemann 2007-12-22 15:38:56 Re: self ordering list