I would definitely like to see an example of a case where a MUCK table was a good solution.  What is the value of this sort of design?  Just fewer tables?  I find that good database design not only enforces data integrity, but helps decode your data for future generations, especially if you're careful about naming conventions.  I've had to reverse engineer more than one database in my career and let me tell you that that above anything else has made me a successful database designer.  As such, I'm willing to acknowledge that certain deviations from convention are necessary for certain applications, I'm just curious as to the actual virtues of these so-called MUCK tables.

~Pam