From: Jamie Tufnell <diesql@googlemail.com>
To: Ray Madigan <ray@madigans.org>
Cc: pgsql-sql@postgresql.org
Subject: Re: Composite UNIQUE across two tables?
Date: Fri, 7 Mar 2008 01:10:14 +0000
Message-ID: <b0a4f3350803061710y2d3391cdwa54d7dcf4af5692f@mail.gmail.com> (raw)
In-Reply-To: <CMEFJOLLJJDJKKLGEJJMGEJDCAAA.ray@madigans.org>
References: <b0a4f3350803061104s89656bcl739e1aa1cdcb6e3a@mail.gmail.com>
<CMEFJOLLJJDJKKLGEJJMGEJDCAAA.ray@madigans.org>
Hi Ray,
Thanks for your reply!
On 3/6/08, Ray Madigan <ray@madigans.org> wrote:
> I don't think I understand. You have a constraint that a user has implied
> access to any site in the group, explain why you think it would be wrong to
> have the group_id as an instance variable fro the user. Otherwise whenever
> the user is in a site in the site group other then the specific site
> represented by the user.site_id the query has to go join with the site to
> find the site group.
That's true. I'll try to explain why it feels wrong...
I already have site_id in the users table and I can determine the
site_group_id from that. So it seems redundant to me, to store
site_group_id for each user as well. Also, I'm not sure how I would
enforce that the site_group_id added to the users table would
correspond correctly with the site_id (as per the sites table).
Perhaps I would make a composite foreign key?
I've never come up against this situation before, and because of the
reasons above, I'm getting the feeling there might be a better way to
design this.
Cheers,
J.
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: diesql@googlemail.com, ray@madigans.org
Subject: Re: Composite UNIQUE across two tables?
In-Reply-To: <b0a4f3350803061710y2d3391cdwa54d7dcf4af5692f@mail.gmail.com>
* 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