I see similar situations quite often. For example I have a database for our supply chain system. We need to store the cost structure of each item, but each item would have a different cost structure, some might have this cost type, but not that, and some would have that but not this.

In this case, it would be a bad idea to store the cost structure in one table, having the items as rows, and each cost component as one column. That's bad, and it is bad because it breaks the rules of normalization.

What I did is to have three tables, one store all the validate items, and one store all the possible cost components. Now I use a third one to store what cost components are involved for each item. This third table only needs three columns (in my case):

1. One column for item numbers, with reference to the valid item table;
2. One column for cost components, with reference to the valid cost components table; (each item would have multiple rows to store its cost structure, but item + cost components is a unique key.)
3. One column for the dollar value of this particular cost component for this particular item.

You have exactly the same pattern of requirement. Your third-parties are my items, and your web page components are my cost components. With this design your tables are fully normalized. This would be the best design on the database side.