Re: problem with table structure - Mailing list pgsql-general

From Alban Hertroys
Subject Re: problem with table structure
Date
Msg-id 49263125-B836-43A6-9C3D-AC1E0E0A32BC@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: problem with table structure  (Miguel Vaz <pagongski@gmail.com>)
List pgsql-general
On 9 Jul 2010, at 17:08, Miguel Vaz wrote:

>
> Thank you for the opinion, Alban. The names are the least of my worries, i typed them without thinking. And its
portuguese.:-) 
>
> If, using that design, i had a different table with something like arq_types { id_arq_type, descr } that i could
somehowconnect to the generic table (the one with the common fields), how could i go about querying those tables for
allthe results of a specific type, for example? Or maybe i could add a "table_name" field on that arq_type table? 


I think you're still referring to your original design here and not to the inheritance approach, right? In that case
youprobably want something like: 

* sites
id_site
name
description
x
y
type_site text REFERENCES site_types

* site_types
type_site text PRIMARY KEY


If you use a natural key here (like I did above) you often don't even need to join with site_types, but it does give
youa constraint what people can type in the field it relates to. 
Note: I'm assuming that a site can only be of one type here, I didn't have enough information to go on so that may be
wrong.It gets slightly more complicated if that's the case. 


If you use table inheritance you'll have to redefine the foreign key constraint on each child table, as the FK
constraintwon't be inherited. 

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4c376755286211334030252!



pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: "attempted to lock invisible tuple" error while update
Next
From: Tim Landscheidt
Date:
Subject: Re: problem with table structure