The longer version of what Andy was explaining is this. You have an Customer's table. You need to tie this to the Orders table. So you have a column in your orders table for the unique id for each customer. This way creating a link between the tables that a join can be built upon. That way you can print - John Doe ordered one Foo and two widgets. John Doe would not be stored in the orders table. However his unique id would be, thus tying all John Does customer info to that order.
At 01:54 AM 9/28/2002 +1000, you wrote: >Sorry if this is such a basic question as to be stupid, but why do you >sometimes have foreign keys? I've looked at MS's Books Online, but that >only tells me how to do it, not why I'd want to, which is typical of >Microsoft's documentation. > > >On my tables in MS SQL2000, I typically have an primary key ID field which >is int, identity, 1, 1 which works fine as far as I've gone, which I'll >admit isn't all that advanced. > > >There is obviously an advantage to having a foreign key, because people do >it, but I'm afraid I am too much a learner to know what the advantage is. > > >Can someone give me a quick explanation of why and/or when its better not to >have the key as a field in the table itself? > > >Cheers, >Mike Kear >Windsor, NSW, Australia >AFP WebWorks > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
