I have a somewhat more complicated scenario, but I think it should be possible.
I have a large SPROC whose result is a set of characteristics for a set of persons.
So the Table would look something like this:
Property | Client1 Client 2 Client3 ----------------------------------------------------------- Sex | M F M Age | 67 56 67 Income | Low Mid Low
It’s built using cursors, iterating over different datasets.
The problem I am facing is that there is a varying number of Clients and Properties, so an equally valid result over different input sets might be:
Property | Client1 Client 2 ------------------------------------------- Sex | M F Age | 67 56 Weight | 122 122
The different number of properties is easy, those are just extra rows.
My problem is that I need to declare a temporary table with a varying number of columns.
There could be 2 clients or 100. Every client in guaranteed to have every property ultimately listed.
What SQL structure would statisfy this and how can I declare it and insert things into it?
I can’t just flip the columns and rows either because there is a variable number of each.
First, you should consider normalizing your design like so:
Second, the SQL language in general is not geared for dynamic column generation. To achieve this, you have to build the SQL statement at runtime (a.k.a. dynamic SQL) as a string. It is best to do this in the middle-tier or a reporting engine rather than in T-SQL.
Third, an infinitely flexible design where you have no idea as to the number or types of properties or instances isn’t a design at all. Each table represents a collection of entities with known attributes. They are not wads of arbitrary data. The attributes (columns) need to be known at design time or you risk a Cthulhu design where nothing but chaos reins.
Will Hughes’ suggestion is to use an Entity-Attribute-Value design (a.k.a. EAV). It takes a tremendous amount of discipline to do an EAV correctly. It only works if it is treated solely as a wad of data. I.e., no developer can ever filter on any specific attribute (i.e. hard code a query looking for a specific attribute name), ever calculate on the values and you will never be able to ensure consistency amongst specific values. If you can maintain that discipline, then an arbitrary wad of data as a limited portion to a larger design can work. However, once you decide to hard code a query looking for a specific attribute you have gone down the dark path and forever will it dominate your destiny. As the database grows, the performance will degrade significantly. You will have no data integrity (e.g. you have two attributes called “Age” and “Client Age” with some values being integers and others being text). EAVs can be a nightmare to maintain. It is far better for maintenance, reporting, querying etc. to have a normalized design.