Re: Question: Entities With Common Attributes

From: JRStern <JRStern_at_gte.net>
Date: Wed, 04 Apr 2001 19:06:29 GMT
Message-ID: <3acb7091.17667214_at_news.gte.net>


On Wed, 4 Apr 2001 05:20:50 +0100, "SQL-er" <SQL-er_at_noemail.com> wrote:
>What is the "accepted way" of handling something like this ?

Well, it seldom occurs like that, without at least a few common fields!

But if it did -- simply have two tables! Now, you want to be sure you don't assign the same number to customers in the different tables, you can do this various ways. If need be, you *could* have a third table containing nothing but customer-number. As above, usually you find a bunch of other fields to keep there, too.

Remember, with either a two or three table solution, you can do most all of your selects via a view that does a union on both, and do inserts through stored procedures that hide the table structure from the application.

Or, you can do as David Cressey suggests and use a one-table solution, that's common (I think he over-interpreted the problem with his five-table solution, it's valid but I don't think it's what you asked!)

Joshua Stern
JRStern_at_gte.net

>A database model for a company sales obviously contains an entity "customer"
>
>But, in this case, there are 2 types of customer - "businesses" and
>"individuals"
>Different attributes are recorded for each type
>
>eg: something like:
>
>Individual-Customer
> Customer-number
> Name
> Phone-no
> Driving-Licence-number
>
>Business-Customer
> Customer-number
> Business-name
> Business-type
> phone-no
> fax-no
>
>So, the customer-number is the only attribute common to both types of
>customer
>But, I don't see how that ought to be handled
>
>I'm probably missing something very obvious here...
>Could someone give me a hint as to what it is ?
>
>
>novice SQL-er ( still learning )
>
>
Received on Wed Apr 04 2001 - 21:06:29 CEST

Original text of this message