>I've been working on a larger project (for me) lately where there will ultimately be 150+ tables. On most of the other projects I've done, I haven't given much thought to normalization. I've looked back on them and most of them seem to be normalized anyways. On this project I've started really looking at how tables are related, etc.
>
> The one issue that has come up is how foreign keys are handled in the normalization process. I started noticing some of my tables (let's call it "Main") have a foreign key to another table ("middle")a foreign key to some third table. Is it bad form to include a direct foreign key in my "main" table? Or is this a case of "it depends"?

The others have told you why you DONT want to have a "shortcut" key from a grandchild to a grandparent. I completely agree. But I also want to add that there are certain rare instances where, for performance reasons, this becomes the only plausible solution. In cases where the tables involved contain a LOT of records (my definition of a lot is > 1 Million), joining three tables can give an intolerable (even with full optimization) delay. Often storing a grandparent key in the grandchild is the only way to get the performance you need. As with any other time you break 3rd normal form, there is a price to pay. Maintaining this key takes extra work, and this practice always gives way to the possibility of conflicting information. You should make sure that any time you break from normal form, you know exactly what you are doing, why, and the price you are paying.