Re: Design question regarding data typing

From: Jacob JKW <jacobcdf_at_yahoo.com>
Date: 24 Feb 2006 06:49:08 -0800
Message-ID: <1140792548.324693.84000_at_p10g2000cwp.googlegroups.com>


Roy Hann wrote:
> "Jacob JKW" <jacobcdf_at_yahoo.com> wrote in message
> news:1140751712.900035.59400_at_v46g2000cwv.googlegroups.com...
> > I currently have a table called Institutions. The table groups data
> > common to all institutions along with a foreign key to the
> > InstitutionType table. Institution types can be let's say either
> > "school" or "bank".
> >
> > The similar characteristics of both schools and banks are all grouped
> > in the Institutions table, and the dissimilar characteristics are all
> > grouped in the Schools and Banks table respectively.
> >
> > I assume this is rather poor DB design.
>
> Why do you assume that? It is a perfectly reasonable design.
It just feels kludgy to me. I'm storing data (the type of institution) that is inherently superfluous as it could be gleaned just by looking at the location of the data within the database.

> > Obviously, one convoluted way to get around this would be to pull all
> > Instutions FKs from the Schools and Banks and then based upon the table
> > in which I found the FK I could determine the type. But that seems kind
> > of silly. Shouldn't I be able to do this without having to do any
> > lookups in the two child tables?
> >
> > so any suggestions on where I'm going wrong and/or how better to
> > proceed?
>
> I don't understand what your problem is. Is it performance? Aesthetics?
> Consistency? Fidelity to the enterprise of interest?
I don't know. Aesthetics, I suppose? I just want to design my database properly. Received on Fri Feb 24 2006 - 15:49:08 CET

Original text of this message