How to represent allocating resources to multiple projects in SQL - sql

Question

I have a SQL Server database with an Access front end where I need users to be able to allocate resources to multiple projects at once. For example, we have a stock of a particular part that is used in a number of mechanical assemblies and we need to allocate these parts to the particular assemblies for production.
How do people normally represent data with these requirements?
Currently my data is stored as follows:
Resource | A | B | C (etc.)
---------+-------+-------+------
a | 10 | 20 | NULL
b | 11 | NULL | 31
c | 12 | NULL | NULL
d | NULL | 40 | NULL
Where A, B, C are different projects.
Advantages:
Easy visualisation and updating of Resources across all projects
Disadvantages:
Database structure changes every time a project is added or finished..
.. therefore many queries need to be rewritten/dynamic
Difficult to get aggregate resource allocation summaries
If old projects are retained, the table could easily exceed the column count limit
Alternatives
It seems to me that a more 'standard' representation would be a table as below. However, I have found it more or less impossible to present this to the user in a way that will allow easy visualisation and resource allocation over multiple projects.
ID | Project | Resource | Quantity
-----+---------+----------+----------
1 | A | a | 10
2 | A | b | 11
3 | A | c | 12
4 | B | a | 20
5 | B | d | 40
6 | C | b | 31
Advantages:
No structural changes when adding/removing projects
Easy resource summaries
Easy archiving of old projects
Disadvantages:
Views that recreate the interface of the top example using JOINs will only allow editing of one column at a time and will not allow insertion or deletion by updating from/to NULL:
e.g.
-- 'Resources' table has resource ID as primary key (& other info about resource),
-- 'ProjectResources' is the 'standard' table above
SELECT ResourceTable.ID, ProjA.Quantity AS A, ProjB.Quantity AS B, ProjC.Quantity AS C
FROM Resources
LEFT JOIN (SELECT ProjectResources.Quantity, ProjectResources.Resource
FROM ProjectResources
WHERE ProjectResources.Project = 'A') AS ProjA
ON Resources.ID = ProjA.Resource
LEFT JOIN (SELECT ProjectResources.Quantity, ProjectResources.Resource
FROM ProjectResources
WHERE ProjectResources.Project = 'B') AS ProjB
ON Resources.ID = ProjB.Resource
LEFT JOIN (SELECT ProjectResources.Quantity, ProjectResources.Resource
FROM ProjectResources
WHERE ProjectResources.Project = 'C') AS ProjC
ON Resources.ID = ProjC.Resource
Using an INSTEAD OF UPDATE trigger on the above view can make it fully editable, but using this view in any further queries to add information (e.g. the 'stock' of the resource that we're allocating) make these fields read only (error along lines of 'field cannot be updated because it it participates in a JOIN and has an INSTEAD OF UPDATE trigger')
Both of the above options require that the front end can cope with a varying number of table columns, which is a bit awkward, though in the second case this requirement can be limited only to specific circumstances.
Are there any other options on how to represent this data and allow easy editing that I have missed?

Answer 1

Your current database schema is not desirable for the reasons you listed. You are probably better off making the schema sensible and then dealing with the view in your UI rather than producing a bad schema to suit a particular view (if you want other views too, you'll be back in the same bucket with a hard-to-use schema for the new view).
While it's possible to produce the view as a crosstab query in Access, you will not be able to edit it (same as you found for your query; you are essentially building a crosstab query manually there).
A potential solution is to generate a temporary table in the front-end with the desired projects as columns (perhaps a subset of all projects), populate it with the resource data from the real table and display it as a datasheet. It will be editable and you can write changes back to the real table. It requires coding but it resolves the disadvantages.