home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 8012 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  2.5 KB
  1. Path: sparky!uunet!portal!cup.portal.com!DVaz
  2. From: DVaz@cup.portal.com (David D Vazquez)
  3. Newsgroups: comp.databases
  4. Subject: Re: MANY-TO-MANY mess in Paradox!!!
  5. Message-ID: <69972@cup.portal.com>
  6. Date: Sat, 21 Nov 92 13:58:09 PST
  7. Organization: The Portal System (TM)
  8. References:  <Bxzoqw.6xo@ccu.umanitoba.ca>
  9. Lines: 58
  10.  
  11. >
  12. >Is it just me or does every one is unhappy withg Paradox's way of handling
  13. >many-to-many links. I always end up with extra tables and lots of redundant
  14. >information. In a typical scenerio (sp?), a product can be supllied by
  15. >many vendors and a vendor can suplly many products. When it comes to 
  16. >displaying either side of this info, paradox suggests extra tables and their
  17. >use in the "form" display/generation. It, however, doesnot suggest an
  18. >answer to following problem....
  19. >
  20. >say, from an input screen I am entering info about new products or new
  21. >suppliers. If its products, it can have a variable number of vendors and
  22. >if it is a vendor, there could be a variable # of products for it. How can
  23. >I design an input screen/form that has linked tables on it and handeles
  24. >multiple entries for a given field. I mean I can use Products as master
  25. >form and use vendors as linked embeded form. Now when ever I enter a new
  26. >product, I am not sure how many vendors for this product there will be.
  27. >Could be 0,1, or 10000!!! How can I design an input screen and then table
  28. >which would handle this situation????
  29. >
  30.  
  31. Many to many relationships should always be resolved.  This feat is ac-
  32. complished by use of an intersection table.  In your example above, the
  33. final database could look like this after the many to many is resolved:
  34.  
  35.   VENDORS
  36.     Name         A10*
  37.     Location     A15
  38.  
  39.   PRODUCTS
  40.     Name         A20*
  41.     Manufacturer A30
  42.     MSRP         $
  43.  
  44.   INVENTORY (you'll have to shrink this down to 8 chars for DOS)
  45.     Vendor Name  A10*
  46.     Prod. Name   A20*
  47.     Quantity     N
  48.  
  49. INVENTORY is the intersection table.
  50.  
  51. For the input screen, you could use VENDORS as the master, embed INVENTORY,
  52. and use PAL to popup a form that you can enter new products on.  This method
  53. is good because it would be a waste of space to keep track of products that 
  54. no vendor has in its inventory.  When a vendor starts supplying a *new* product
  55. ,
  56. you could add it to the product list, then the product will be available when
  57. other vendors add it to their inventory.
  58.  
  59. If you decide to make PRODUCTS the master and embed INVENTORY, you'll have to 
  60. reverse the order of INVENTORY's key.
  61.  
  62. >Thanks very much for help.
  63. >
  64. >Malik
  65. >ummalik@ccu.umanitoba.ca
  66.  
  67.   You're welcome
  68.   -Dave.  "dvaz@cup.portal.com"
  69.