[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).

No, it would need a m-m between contact and type so that the same contact
can be as many different types as needed.  And the reason it got in the book
that way is that it makes it simple enough for Joe average user to
understand.  The focus was apparently not correct normalization but
something else.

I actually built my LightWeight Security around a 32 bit (actually 31 bit)
word (long int in VBA) to represent user groups.  I did it that way because
the whole thing revolved around classes which loaded and cached this stuff
and then the classes interpreted everything in code.  I don't care (in my
code) what a given bit represents, it is just "some group".  I made an
executive decision that for my use, 31 groups was sufficient.

Perhaps this author has a similar "executive decision".

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 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