[AccessD] Contact Database Design III.

David,

  Yes, that could certainly be an explanation.  Unfortunately, there is no
application provided that goes against this database, so there is no way to
tell if that would be allowed or not.  

Jim.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson
Sent: Thursday, May 31, 2007 3:09 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Contact Database Design III.

Could it be that by using the bit fields the same contact could be 
noted as customer and employee.  If a single type field was used then 
the person would need to be entered twice (once for each type).

David

At 1/06/2007, you wrote:
>John,
>
>   Yes, the bit field is what really threw me.  I can't understand why it
was
>not done as a single field.  Seems to be a really poor design.  I'd love to
>talk to him sometime about how and why it made it into the book that way.
>
>Jim.
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
>Sent: Thursday, May 31, 2007 1:56 PM
>To: 'Access Developers discussion and problem solving'
>Subject: Re: [AccessD] Contact Database Design III.
>
>Having a FK in the table for the type makes sense.  Having a bit field
seems
>rather limiting and harder to filter for.
>
>
>John W. Colby
>Colby Consulting
>www.ColbyConsulting.com
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
>Sent: Wednesday, May 30, 2007 5:03 PM
>To: 'Access Developers discussion and problem solving'
>Subject: [AccessD] Contact Database Design III.
>
>Hi All,
>
>   Stumbled across something today that I thought I'd pass along in regards
>to contacts.  I have the book "Microsoft SQL Server 2000 Bible" by Paul
>Nielsen as one of my reference books sitting on the shelf.  Happened to
>notice today one of the sample SQL databases included had a contacts table.
>Direct quote from a description of the database:
>
>"For simplicity, all contacts are merged into a single table and the
contact
>type is signified by flags.  A contact can be a customer, employee, or
>vendor.  Customers have a lookup for customer type, which is referenced in
>determining the discount."
>
>   Literally he has three bit flag fields in the record to indicate if it
is
>a customer, employee, or vendor contact.  It also includes name fields and
a
>company name, so the contact can be a person, a company, or a person at a
>company.
>
>   Suffice to say I was quite surprised to see this.
>
>   BTW, I'm still going back and forth between doing a single table vs one
>for individuals and one for companies.  Even before I had seen the above, I
>was leaning towards going back to a single table.  I'll let you know what
>approach I finally choose when I get to it and any pitfalls that ensue as a
>result.
>
>Jim.
>--
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>--
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>--
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com