Great example and my apologies because as you know we've been down this road before.
Side note - once again I did not provide my acutal table names , this time they haven't been created as of yet. Let me skinny this down though a bit and focus on one aspect of my design connundrum. Remember I am designing for a "job board". Users can choose say up to 3 locations where they would like to look for work. So if my thinking is correct , this is a possible schema: Users_table * Location_table * Users_Location_table (the - MTM) Now I think the above is right, but I ask myself, what are the real drawbacks if I do something like this: Location_table: indentifying fields .(userID's, recordID's).. Location1 Location2 Location3 This is the point I know that is sticking me - understanding why the first example is better then the second. Thank you , Stuart --- [EMAIL PROTECTED] wrote: > Tables are tied together by whichever field(s) you > use to store their > "parent"'s reference. > > For one second, imagine I am writing an inventory > control program for > somebody like Wal-Mart or Target. Those businesses > have so many locations > that they are divided into regions, each region will > have multiple > warehouses, each region would also have multiple > stores. Each store could > be within supply range of several warehouses. Each > warehouse can supply > several stores. > ................. > Shawn Green > Database Administrator > Unimin Corporation - Spruce Pine -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
