fe6c44ed   
   From: geoff.muldoon@trap.gmail.com   
      
   Edward says...   
   > I've been tasked with designing an application to capture data about   
   > sports clubs.   
   >   
   > Let's say there are four different types of club - Soccer, Cricket,   
   > Rugby and Tennis.  For various reasons it is essential that data about   
   > each of these will be stored in its own table.   
   >   
   > I want to make use of the new datatype Geography to store the location   
   > data.  Unfortunately, LINQ to SQL doesn't yet support these.  So my   
   > thinking is to keep the location data in a separate table and   
   > manipulate the data server-side to enable CRUD operations, but   
   > ensuring that messages containing location information are in a form   
   > that Visual Studio can deal with (by parsing in UDFs etc).   
      
   My view:   
      
   create table locations (location_id, location_information, ...)   
   create table club_types (club_type_id, club_type_desc)   
   create table clubs (club_id, club_name, club_type_id, ...)   
   create table location_suitability (location_id, club_type_id, ...)   
   create table club_locations(club_type, club_id, location_id, ...)   
      
   Why?  Because there is the possibility (probability?) that clubs might   
   share a location (site suitable for both rugby and soccer for example).   
   And perhaps a club may have multiple locations.   
      
   Depending on scope, you might even have a location_activity_type (playing,   
   training, admin) table.   
      
   If your "various reasons" produce an overwhelming argument, then and only   
   then split the clubs into separate tables per type.   
      
   GM   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)