Re: Best practice on inherited tables

Поиск
Список
Период
Сортировка
От Alfonso Afonso
Тема Re: Best practice on inherited tables
Дата
Msg-id 058EDA0A-9929-4C02-8815-B13F10ED2F20@gmail.com
обсуждение исходный текст
Ответ на Best practice on inherited tables  (Frank Lanitz <frank@frank.uvena.de>)
Ответы Re: Best practice on inherited tables  (Frank Lanitz <frank@frank.uvena.de>)
Список 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
followthe 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
coulduse 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@frank.uvena.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

Alfonso Afonso
(personal)







В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Amiel
Дата:
Сообщение: Re: Why does row estimation on nested loop make no sense to me
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Why does row estimation on nested loop make no sense to me