Thread: Avoiding duplications in table.

Avoiding duplications in table.

From
Deepa K
Date:
Hi All,
                I have the following tables.

 tablename : versions       tablename :
applicationmanager                     tablename : applications

versionnumber-string              versionnumber -
string                                 applicationnumber - integer

applicationnumber - integer                        other details


tablename : profilemanager            tablename : profiles

versionnumber : string                        versionnumber : string
profilename : string                                profilename : string

applicationnumber : integer
otherdetails

Primary key :
---------------

(1)    versions : versionnumber
(2)    applicationmanager : versionnumber, applicationnumber
(3)    applications : applicationnumber
(4)    profilemanager : veriosnnumber, profilename, applicationnumber
(5)    profiles : versionnumber, profilename

Relations :
-----------

(1)    versionnumber of 'applicationmanager' referes to versionnumber of
'versions' table.
(2)    applicationnumber of 'applicationmanager' referes to
applicationnumber of 'applications' table.
(3)    versionnumber and applicationnumber of 'profilemanager' referes
to versionnumber and applicationnumber of 'applicationmanager'.
(4)    versionnumber and profilename of 'profilemanager' referes ot
versionnumber and profilename of 'profiles'.
(5)    versionnumber of 'profiles' referes to versionnumber of
'versions'.

In the above design I can able to see duplication of data in all the
tables. If I take out a id out of all these tables to make reference, is
that problem will solve. Is that is
a correct approach.

Can any one help me.

regards,
Deepa  K


Re: Avoiding duplications in table.

From
Dennis Gearon
Date:
For us not to struggle to read what you are doing,
please reformat your table definitions along the lines of:

tablename1
    column_name1, type
    column name2, type
    column name3, type

tablename1
    column name1, type
    column name2, type
    column name3, type

or

full fledged table creation statements a la:

CREATE TABLE PhonNums(
    phone_num_id serial NOT NULL PRIMARY KEY,
    phon_num varchar(32) NOT NULL UNIQUE,
    created timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL
);


PS one of the recommended ways to name attributes in a database design are:

Schemas        'ALL_CAPS_SEPARATED_WORDS' (this is a guess)
TableNames     'BumpyCaps'
FieldNames     'lower_case_underscore_separated_words'
SQLWords     'SHOULD BE ALL CAPS'
Keys/Indexes     'Often_Are_Found_With_Leading_Caps_And_Underscores'
Functions     'One_leading_cap_with_underscores' - i really don't know

Of course, PGSQL and other databases will change some of those to all caps or
all lowercase. But for readability, naming db attributes this way in SQL
statements and functions etc, helps a lot.



Deepa K wrote:
> Hi All,
>                 I have the following tables.
>
>  tablename : versions       tablename :
> applicationmanager                     tablename : applications
>
> versionnumber-string              versionnumber -
> string                                 applicationnumber - integer
>
> applicationnumber - integer                        other details
>
>
> tablename : profilemanager            tablename : profiles
>
> versionnumber : string                        versionnumber : string
> profilename : string                                profilename : string
>
> applicationnumber : integer
> otherdetails
>
> Primary key :
> ---------------
>
> (1)    versions : versionnumber
> (2)    applicationmanager : versionnumber, applicationnumber
> (3)    applications : applicationnumber
> (4)    profilemanager : veriosnnumber, profilename, applicationnumber
> (5)    profiles : versionnumber, profilename
>
> Relations :
> -----------
>
> (1)    versionnumber of 'applicationmanager' referes to versionnumber of
> 'versions' table.
> (2)    applicationnumber of 'applicationmanager' referes to
> applicationnumber of 'applications' table.
> (3)    versionnumber and applicationnumber of 'profilemanager' referes
> to versionnumber and applicationnumber of 'applicationmanager'.
> (4)    versionnumber and profilename of 'profilemanager' referes ot
> versionnumber and profilename of 'profiles'.
> (5)    versionnumber of 'profiles' referes to versionnumber of
> 'versions'.
>
> In the above design I can able to see duplication of data in all the
> tables. If I take out a id out of all these tables to make reference, is
> that problem will solve. Is that is
> a correct approach.
>
> Can any one help me.
>
> regards,
> Deepa  K
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>