Stop designing a physical model and design your logical model first. Once
you have the logical model, converting to a physical model is easy.
"Chris" <chris_at_cjetech.co.uk> wrote in message
news:220db75.0309170535.21a6a49b_at_posting.google.com...
> Hi,
>
> I have found a problem that I can't seem to solve in what I consider a
> nice way.
>
> Basicly I have a table called Jobs. Each Job has some details in its
> table, it also has a type. These are A, B, C, D, E and F. If it is
> of type A then it needs an additional 10 columns, B 13, C 30 and so
> on. These additional piecies of information are totally unrelated to
> those in a different letter. How do I represent this?
>
> My first thought was to have a Jobs table which has a foreign key
> pointing to a Type table, which lists the types, and then a column
> which has a foreign key to either Table A, Table B, Table C etc. This
> would them mean that there was a foreign key that pointed to different
> tables depending on what another column's data said.
>
> Is that even slightly valid relational database thinking? If not what
> is a better solution? All I could really think of was having an A_key
> column, a B_key column etc, but then there would be loads of null
> data.
>
> Cheers,
>
> Chris
Received on Wed Sep 17 2003 - 12:16:59 CDT
