From: | Alfonso Afonso <aafonsoc(at)gmail(dot)com> |
---|---|
To: | Frank Lanitz <frank(at)frank(dot)uvena(dot)de> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Best practice on inherited tables |
Date: | 2013-05-17 19:21:35 |
Message-ID: | 058EDA0A-9929-4C02-8815-B13F10ED2F20@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Frank
Although you are thinking in OOP, the SQL is itself one definition model that you should not ignore and, IMHO, try to follow the normalization statements.
You can build a robust and normalized schema (table primarylocation , table secondlocation that have a idprimarylocation, etc.) and later you could build your OOP software translating this to the proper classes (in Java you could use a DAO-POJO class or hibernate-jpa, for example).
With this solution you can obtain all the benefits of DBRMS besides a OOP robust software :)
Best regards
El 17/05/2013, a las 13:46, Frank Lanitz <frank(at)frank(dot)uvena(dot)de> escribió:
> Hi folkes,
>
> I'm looking for a nice way to build this scenario:
> I've got a lot of locations with some special types. For example I've
> got workplaces, places like real laboratories and virtual places like
> maybe parcel service. For each of the different types I need to store
> some common attributes as well as some special ones. Having OOP in mind
> I came to the point of inherit tables. so I've create something like
> that (just a minimal example):
>
> CREATE TABLE locations(
> id SERIAL PRIMARY KEY,
> name varchar(50)
> );
> CREATE TABLE workplaces(
> workers integer
> ) INHERITS (locations);
>
> But now I got stuck with the primary key thing. As described in the
> documentation it is not supported. And now I'm looking for the best way
> on having at table workplaces also the unique constraint from locations
> etc. so e.g. I can do something like that:
>
> INSERT INTO workplaces (name, workers) VALUES ('My Place', 5);
>
> having the incrementation and the uniqueness. I was thinking off
> creating a number of triggers doing this for me but wondering whether
> there might be a better way.
>
> Cheers,
> Frank
>
> BTW: Using Postgres 9.2 and up
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
Alfonso Afonso
(personal)
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2013-05-17 19:21:47 | Re: Why does row estimation on nested loop make no sense to me |
Previous Message | Jeff Amiel | 2013-05-17 18:31:16 | Re: Why does row estimation on nested loop make no sense to me |