home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / database / 1485 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.8 KB

  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!azores!sprattli
  2. From: sprattli@azores.crd.ge.com (Rod Sprattling)
  3. Newsgroups: comp.sys.mac.databases
  4. Subject: Re: Restricting selection
  5. Message-ID: <1992Nov20.212832.1244@crd.ge.com>
  6. Date: 20 Nov 92 21:28:32 GMT
  7. References: <1992Nov19.054912.5580@seas.gwu.edu>
  8. Sender: usenet@crd.ge.com (Required for NNTP)
  9. Reply-To: sprattli@azores.crd.ge.com (Rod Sprattling)
  10. Organization: GE Corporate R&D Center
  11. Lines: 68
  12. Nntp-Posting-Host: azores.crd.ge.com
  13.  
  14. In article <1992Nov19.054912.5580@seas.gwu.edu>, willson@seas.gwu.edu
  15. (Stephen R. Willson) writes:
  16. |>    Monday's baseball expansion draft got me thinking about a database
  17. |>question.  During at least the first round of the draft, no more than one
  18. |>player from each team could be taken by Tampa or Denver.  If I for some
  19. |>reason had setup a database of all the players eligible for the draft, how
  20. |>could I implement this restriction.  If one player from the Boston Red Sox
  21. |>has already been selected, how could I lock out selecting a second player
  22. |>from the Red Sox?  Does a database program exist that makes such
  23. |>restrictions easy to implement?  One particular application which I am
  24. |>interested in is evaluating economic proposals which are either mutually
  25. |>exclusive, mutually dependent, or mutually independent of other proposals.
  26. |> Does anyone have experience with designing a database for such an
  27. |>application?
  28. |>
  29.  
  30. For a relational solution, create three tables: Team, Player and Contract.
  31.  
  32. Each Team record describes a team, and is indexed by TeamID.
  33.  
  34. Each Player record details a player, and is indexed by PlayerID.
  35.  
  36. The Contract table describes the relationship between Team and Player.
  37. In SQL it might look like this:
  38.  
  39. create table Contract
  40.     (TeamID number not null primary key
  41.      PlayerID number not null,
  42.      Draftable boolean);
  43.  
  44. If the Draftable bit is FALSE, then that player is currently under contract
  45. to that team. If the Draftable bit is TRUE then the player is currently
  46. under contract to that team but is eligible for the draft.
  47.  
  48. Set all Draftable fields to TRUE before start of each draft season.
  49.  
  50. The SQL-ish query
  51.  
  52.     select TeamID into :teamID
  53.     from Contract
  54.     where PlayerID = :playerID and Draftable = 'TRUE';
  55.  
  56. will tell you if playerID is available for draft.  If so, the statement
  57.  
  58.     update Contract
  59.     set Draftable = 'FALSE'
  60.     where TeamID = :teamID;
  61.  
  62. will mark the player and his team mates unavailable for further draft.
  63. The final statement
  64.  
  65.     update Contract
  66.     set TeamID = :newTeamID
  67.     where TeamID = :teamID and playerID = :playerID;
  68.  
  69. will associate the player to his new team.
  70.  
  71. Surely there are other things one would want to capture in a bona fide
  72. system such as draft round, contract history, and so forth.
  73. ---                  
  74. Roderick Sprattling        | No job too great, no time too small
  75. sprattli@azores.crd.ge.com    | With feet to fire and back to wall.
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.