Difference between views & inheritence sage - Mailing list pgsql-general

From
Subject Difference between views & inheritence sage
Date
Msg-id 00fb01c1d18f$192295b0$6501a8c0@calvin
Whole thread Raw
List pgsql-general
Hi all

I am considering to solve the following problem.
I need a prompt table (table for providing choices) & transalation tables an
app.

The quickest way to describe the data I am willing to hold is really with a
Java like declarative syntaxe showing the data it should hold.

/** Basically what are the supported languages*/
Languages[] = {"EN", "FR", "NL"};


/** What is the translation for a CODE on a Screen in a specific language */
Transalations [][] =
{
    {"EN", "SCR_1", "CODE1", "English text for the code CODE1 in the screen
SCR_1"},
    {"FR", "SCR_1", "CODE1", "French text for the code CODE1 in the screen
SCR_1"},
    {"NL", "SCR_1", "CODE1", "Dutch text for the code CODE1 in the screen
SCR_1"},
    {"EN", "SCR_2", "CODE2", "English text for the code CODE2 in the screen
SCR_2"},
    {"FR", "SCR_2", "CODE2", "French text for the code CODE2 in the screen
SCR_2"},
    {"NL", "SCR_2", "CODE2", "Dutch text for the code CODE2 in the screen
SCR_2"},
    {"EN", "SCR_1", "CODE3", "English text for the code CODE3 in the screen
SCR_1"},
    {"EN", "SCR_1", "CODE4", "English text for the code CODE3 in the screen
SCR_1"}
}

Currently created like this :
create table translations ( lang char(2) references languages,   screens
char(10) references screens, code char(20) not null, primary key (lang,
screens, code), transalation char(50) not null );
External references see below.

Now this is the generic form of the problem I wanna solve.

There is of course the intermediate tables.
PromptValues[][] =
{
    {"EN", "SCR_1", "CODE1", "English text for the code CODE1 in the screen
SCR_1"},
    {"EN", "SCR_1", "CODE1", "French text for the code CODE1 in the screen
SCR_1"},
    {"EN", "SCR_1", "CODE1", "Dutch text for the code CODE1 in the screen
SCR_1"},
}
and its twin brothers, the list of screens & the list of codes per screens.
The point is to reach a level of intelligent constraints so a code can only
be defined on a screen (should the value be "DEFAULT",meaning it's available
to allthe screens (for OK / cancel / quit / ... buttons, for instance).


To fil up a Combo or to fill up a tables.
My question is :
    Is there a proper way to solve this with inheritence ?



I wanna create it that way because I feel it's a proper way to solve it but
I am not sure.
There is also Loads of integrity constraints & I though the best way to
solve this was to go via inheritence with integrity constraints refering to
the parent table
I though working out Smthg like :
        Create a table "Languages" (1 column)
        Create a table "Codes" (1 column)
        Create a table "Translations"
                Smthg like :
                    create table translations (
                                pk integer primary key default next_oid,
                                lang char(2) references Languages,
                                code char(10) references codes,
                                translations char(50) not null );


        Create a table Prompt table :
            Smthg like
                create table PromptTable (
                            screen char(10)
                            ) inherits (translations);

        Create a table ScreenTranslation:
            Smthg like
                create table ScreenTranslation (
                            screen char(10),
                            primary key (lang, code, screen)
                            ) inherits (translations);

The other approache is with views...
May be beter ?

thomas,




List of screens
    create table screens ( screencode char(10) primary key,  description
char(50) not null);
Languages
    create table languages (lang char (2) primary key);



--
Thomas SMETS
rue J. Wytsmanstraat 62
1050 Bruxelles
yahoo-id : smetsthomas



pgsql-general by date:

Previous
From: Heiko Klein
Date:
Subject: Re: Huge Performance Difference on Similar Query in Pg7.2
Next
From: "Luis Alberto Amigo Navarro"
Date:
Subject: Re: Huge Performance Difference on Similar Query in Pg7.2