Say TABLE-A can have one or more rows in TABLE-B, which can have one or more rows in TABLE-C, which can have one or more rows in TABLE-D ... and so on.
Say I am at TABLE-Z and need to know details about TABLE-A. Do I make a SQL query that works from TABLE-Z all the way to TABLE-A? At some point, maybe it would be nice if, say, TABLE-Z had a FK to TABLE-A so that querying won't be so painful. However, if I put that FK, I think I would be breaking normalization, right?
General advice on how to deal with this?
If you use composite Primary Keys (which would actually happen if you modelled the design correctly before creating any tables) then the key from TableA is already contained in TableZ (as the left most column).
However, folk typically add a surrogate key without understanding why. So this you need to join all 26 tables to establish the link between TableA and TableZ
An extra FK between TableA and your TableZ may conflict with some intermediate foreign key;: this is why denormalised (or unnormalised) data has inherent risks and should be used judiciously.
However, you wouldn't typically have 26 levels of nested table. Working with 2, 3 or even 6 way primary keys means I can join TableA to TableF without any intermediate tables.
Personally, I'd use composite keys and avoid an extra FK unless I had a known, reproducible and demonstrable bottleneck. Most databases won't notice any difference.. so don't optimise just yet