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
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 |