AVB (8/25/2013)
No testing has been done yet as I'm in a "merged" logical and physical design phase.
Beware premature optimisation (making non-standard, over-complex design decisions based on untested performance assumptions)
You're looking at making the database bigger, removing any update/delete constraints for these lookups, adding extra code, unusual check constraints in a non-standard way of doing things that could lead to unanticipated errors when changing data in the child table, with no testing to see if the foreign key/join design it'll be replacing is inefficient.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability