• I'll be perfectly honest, I don't understand most of what you're trying to describe.

    From the description, you've wondered extremely far afield of traditional relational storage. As soon as you start doing this, you will run into trouble. I can't be sure from your description, but, guessing here, maybe SQL Server is not the way to go. Maybe you would better off with something like MongoDB (which uses ID/Value pairs for just about everything). Storage on a system like that is great, but for reporting you have to go back to coming up with an actual structured storage system with good relationships on the table.

    SQL Server is a relational storage engine. That has a series of rules predicated around the concept of some type of primary key that is used to create relationships to other tables through referential constraints, called foreign keys. It's just not designed to store referential information as data from which you can then join tables. It doesn't work well.

    If you have to do something like that because you're dealing with an existing, problematic, design, then your best bet is to pull the data from tables and generate ad hoc t-sql that you can then execute using sp_executesql.

    Hopefully this helps a little.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning