From: | E H <edgeofmyhand(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | [GENERAL] Schema design / joins |
Date: | 2010-05-03 04:52:17 |
Message-ID: | 7027958f-bbe6-4571-9659-71dc4b317344@e2g2000yqn.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Hi,
This is more of a general schema design, any advice is much
appreciated.
I have a Organization table. Nearly every other table in the schema
is related to this Org table in some way. So, some tables may be 3 or
4 tables 'away' from the Org table. In order to filter by the org_id,
I need to join a bunch(?3-6) of tables
Simple example below, TeamFees belong to a Team, which belongs to a
Season, which belong to an Org. In order to get all the TeamFees that
belong to a given Org, I need to join all the tables which isn't a big
deal, but I'm just wonder if putting an extra 'org_id' on Team fees
would help anything...
** Is it a bad idea to put an extra FK 'org_id' on the TeamFees table
to avoid all the joins?
** What about putting an 'org_id' on every table? (it seems somewhat
redundant/unnecessary to me)
I've never had any formal education in rdbms, but from what I can
gather, foreign keys are meant to ensure data consistency, not reduce
the number of joins required. Although, it sure seams like it would
simplify the queries if I stuck extra 'org_id' columns in certain
places. I don't have any particular reason that I'm trying to avoid
joins -- I'm just wondering if there is something simpler or if 'thats
just how it is.'
I would really, really appreciate any suggestions from folks with
rdbms schema design experience! Thanks!
__Orgs__
id
name
__Seasons__
id
org_id fk(orgs.id)
name
__Teams__
id
season_id fk(seasons.id)
name
__TeamFees__
id
team_id fk(teams.id)
*org_id <--- (?put extra fk here to avoid many joins?)
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Gaab | 2010-05-03 11:16:31 | WAL-files restore and nextval('PK') |
Previous Message | Kaveh Mousavi Zamani | 2010-05-03 02:12:18 | Prevent Domain Compare |