[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