From the docs:

"Do not define more than one foreign key on a single non-PK field. Some people define more than one foreign key constraint on a single, non-primary key field and point these to two or more different table's primary key fields. This is bad schema design, even though SqlServer allows you to do this: LLBLGen Pro can't determine this way to which table (entity) the entity with the multi-fk constraints on one field relates to, using the field with the fk constraints. "

I 100% agree, whether you are using LLBLGen or not.

I think the basic reason is that you can no longer completely rely on set theory to retrieve data. You may have to write procedural logic ("if type is customer then <query1> else <query2>").

I had an argument (very friendly) with a coworker today about this. Can anyone point to some resources that explain why this is a bad design?