From: David W. Fenton on
John W. Vinson <jvinson(a)STOP_SPAM.WysardOfInfo.com> wrote in
news:0nu7j5dkp74uund4l3r56r961e2ltkhsvh(a)4ax.com:

> What if a vendor (for one product) is also a customer (perhaps for
> a different product)?
>
> What if a customer becomes a vendor?
>
> You'll do much better to add a separate PersonType field and not
> try to apply "intelligence" to your numeric ID.

And for the customer who is also a vendor, you'll need to use a
separate join table between your Person table and your PersonType
lookup table so that you can have more than one PersonType.

This is much more common than most people would think. I've almost
never encountered a case where customers and vendors did not overlap
at least once or twice, and often quite a lot more often than that.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on
"malik via AccessMonster.com" <u49026(a)uwe> wrote in
news:a11b731947c25(a)uwe:

> If still u can not understand, let me know,,, may be i would be
> able to explain it more deeply

Your structure is still wrong. You're trying to do too many things
in a single table, and a string of Boolean fields is very often
evidence of a possible design error. Both your PersonType (which
you're trying to encode in the ID field) and your three Is...
Boolean fields cry out to be moved to another table, the PersonType
in an N:N join table between Person and the PersonType lookup table,
and the Is... Boolean fields to a 1:N table with 0 or more records
for each person.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/