[AccessD] Re: A2003: Design Question

The "sleek" solution is to design the database correctly.  :-)

tblParty
PartyID  Autonumber (pk)
PartyFullName
PartyFirstName
PartyMiddleName
PartyLastName
etc.....

If a client can also be a franchise, then you would need a table to break 
out the PartyType.

tblPartyType
PartyTypeID  Autonumber (PK)
PartyID  long integer  (fk)
PartyType   text(20)

Otherwise, add PartyType to tblParty.  By doing this, you can populate the 
TimeBilling table with which ever and never worry about it.

Robert

At 12:01 PM 11/16/2004 -0600, you wrote:
>Date: Tue, 16 Nov 2004 12:03:48 +1100
>From: "Darren DICK" <d.dick at uws.edu.au>
>Subject: [AccessD] A2003: Design Question
>To: "'Access Developers discussion and problem solving'"
>         <accessd at databaseadvisors.com>
>Message-ID: <200411160103.iAG13udQ009199 at cooper.uws.edu.au>
>Content-Type: text/plain;       charset="us-ascii"
>
>Hi Team
>I Have a dB that holds data for both Clients (tblClients) and Franchises
>(tblFranchises)
>
>The tblClients holds all the usual client detail stuff - ClientID is the PK
>(Autonumber)
>tblFranchises holds various bits of information about any particular
>franchise - FranchiseID is the PK (Autonumber)
>
>So essentially 2 entity groups within the dB.
>
>BUT my client does work for both the Franchises and individual Customers.
>In order to present both of them in a TimeBilling Screen I use a union query
>to 'merge' both
>groups into a single combo
>
>The problem is storing the PK correctly. eg say I select the 4th Franchise
>in the list - it has a PK of 4
>Well an entry on the client side will also have a PK of 4.
>
>I am tossing up with various ways to deal with this including merging both
>tables into one
>table and just setting a flag to differentiate Clients from Franchises.
>Of course I can have separate fields in the tblTimeBilling for FranchiseID
>and for ClientID.
>
>Just not sure what would be a sleek solution :-))
>
>I am sure this is a common type of thing - I just wanted to know some
>methods on
>how you guys deal with this sort of design question.
>
>Many thanks
>
>Darren
>