I have a table that looks like this:
RECIPE VERSION_ID INGREDIENT PERCENTAGE
4000 100 Ing_1 23,0
4000 100 Ing_100 0,1
4000 200 Ing_1 20,0
4000 200 Ing_100 0,7
4000 300 Ing_1 22,3
4000 300 Ing_100 0,9
4001 900 Ing_1 8,3
4001 900 Ing_100 72,4
4001 901 Ing_1 9,3
4001 901 Ing_100 70,5
5012 871 Ing_1 45,1
5012 871 Ing_100 0,9
5012 877 Ing_1 47,2
5012 877 Ing_100 0,8
5012 879 Ing_1 46,6
5012 879 Ing_100 0,9
5012 880 Ing_1 43,6
5012 880 Ing_100 1,2
There are 100 ingredients per recipe/version. I'd like to display the data from this table like this:
RECIPE INGREDIENT_Vxxx PERCENTAGE_Vxxx INGREDIENT_Vyyy INGREDIENT_Vyyy (ETC)
4000 Ing_1 23,0 Ing_1 20,0
4000 Ing_100 0,1 Ing_100 0,7
Because in different versions of recipes, ingredients could be removed or added, I'd like to display both ingredient and percentage per version per recipe. There's also the difficulty that different recipes have different number of versions.
I'm not even sure if this is possible at all or where to begin. Maybe with the PIVOT
function?
Could anyone please point me in the right direction?
Best Answer
The problem here seems to me to be largely more of a scoping issue - you are likely having difficulty solving this problem on account of the requirements not being defined well enough. With the description and sample data provided, there are at least three partial solutions, none of which may be applicable to your particular use cases. With the test data set up as follows,
we can use our new table to explore some possible solutions. Expanding on the sample output, we add the next recipe into the result set to illustrate the difficulty with the question.
Columns
%_V100
and%_V200
make perfect sense in the case of the4000
recipe, but quickly lose their meaning as additional recipes are added. The4001
recipe would need new and separate columns to properly label the data by version, but since the version numbers differ for each and every recipe, that path leads us to a very sparse result set which would be downright annoying to use, or we must alias the columns, losing the version number data.Solution 1:
Starting with what I feel is the absolute worst way of going about this, let's look at the sparse result set. For the sample data, we would be attempting to generate a query which would look like something along the following lines:
On account of the variable number of versions, we can use some dynamic SQL to generate and execute the query.
This result set plainly sucks. Here's an SQL Fiddle which displays the results, take a peek and let's move on.
Solution 2:
With the sparse result set proving to be next to useless, we can accept losing the version numbers of the recipes and simply order them in ascending version number. For the purpose of the example we'll alias alphabetically, so that versions
100
,200
and300
of recipe4000
will receiveA
,B
andC
designations, whereas versions900
and901
will receive justA
andB
. The query we would like to generate for this should look somewhat like the following:Similarly to solution one, dynamic SQL can be leveraged to accomplish this.
This ends up in a much prettier result set, as can be seen in this SQL Fiddle, despite the loss of the specific version numbers of each recipe.
Solution 3:
If the loss of the version numbers can not be tolerated, a hybrid approach can be implemented, though the results from each call would be limited to only a single recipe. In effect, our goal SQL would be similar to the first solution, but with an expressly defined
Recipe
number.Generation could be handled as follows:
The results could then be accessed per recipe, as shown in this SQL Fiddle or this one.