From: David W. Fenton on 26 Dec 2009 15:33 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 26 Dec 2009 15:35
"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/ |