[AccessD] Contact Database Design III.

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