First and foremost a database is designed in order to establish order out of chaos.  It contains data to facilitate information sharing; however, it contains rules by virtue of relational priciples that provide meaning to that information without which no understanding is passed on to the end-user.

Who cares whether or not a particular database solution would or would not work for an application?  Who cares about performance?  Performance is a secondary requirement, not the first.  Performance can be improved by hardware, by physical database mechanisms, and, yes, by properly normalized database design.

The database should be, must be, designed for the Business Model it is trying to mimic, nothing more, nothing less.

Applications are designed to provide specific actions in the context of the GIVEN, not created, database model.

The whole context of whether or not MUCK tables would be good here or there or in this or that application is pointless.  They are a bad database design for all applications...period.

If you want a MUCK and you want the application to manage those rules, feel free.  Create a VIEW that UNIONs all the entities together for you, create a class, embed and "encapsulate" all of the code muck you'll have to create to maintain it, and present it to whatever application desires its usage.  Although, I will presume it will have performance "issues."

But for the database, follow the rules...the relational rules.