I have to be doing something wrong here.
If I have an Address and an AddressType, I find that the AddressType gets re-inserted when I create an Address, set the type, and save:
MyDataContext ctx = new MyDataContext();
Address a = new Address();
a.AddressType = AddressType.Get("Billing");
a.City = Chicago;
ctx.Addresses.InsertOnSubmit(a);
ctx.SubmitChanges();
The 'Get' uses a different context (of course). In certain more complicated situations (which is where I started at before I spiked this simple example), the SubmitChanges call will fail because it doesn't like that a different context was used to get the AddressType. You can make the get not track changes, but then you get the same issue.
This can't possibly be correct. This makes LINQ to SQL almost completely useless for anything.
I must be doing something wrong, it can't be this bad that you can't create a new Address, set its AddressType, and have your lookup table inserted into.
Update:
The following gets around the immediate issue:
LinqDataContext ctx = new LinqDataContext();
Address a = new Address();
a.AddressType = AddressType.Get("Billing");
ctx.AddressTypes.Attach(a.AddressType, false);
ctx.Addresses.InsertOnSubmit(a);
a.Address1 = "3505 North Claremont, #1";
ctx.SubmitChanges();
Now, this still strikes me as sub-optimal. As you can imagine, it seems as if for a more developed Address object, you would have to attach (and you must use 'false') all dependent objects and so in a more complicated scenario, where the Address object itself is just a part of a checkout process, you end up having to do way too many attaches. I'm going to see if this is the case. It does work for this limited case, so I'll go with it for now.
Another Update:
I go into a more comprehensive way of using Linq to SQL and ASP.Net here.