I have a table structured like this:
ProjectID | Field1 | Field2 | Field3 | ...
------------------------------------------
1 | aaa | aaa | aaa | ...
------------------------------------------
2 | aaa | aaa | aaa | ...
------------------------------------------
3 | aaa | aaa | aaa | ...
------------------------------------------
1 | aaa | aaa | aaa | ...
------------------------------------------
1 | aaa | aaa | aaa | ...
------------------------------------------
2 | aaa | aaa | aaa | ...
and some external systems that need to access this table to read data and write back one value at the and of the process.
The problem is that each external system will have to access only data related to his project, I.E.:
- System 1 -> ProjectID = 2
- System 2 -> ProjectID = 3
- System 3 -> ProjectID = 1
I’d like to keep this data separated to avoid errors because these systems will be developed externally from our application and I can’t assume that they will use only their data.
I came across two solutions:
- Create a table for each ProjectID in a different DB schema, and give to every external system only the credentials to access their table.
- Create an updateable view for each ProjectID that extracts data only for a specific project, and give to every external system only the credentials to access their view.
Any other ideas?
Thank you!
So if my other answer about an API won’t work for you, then the appropriate way of handling this securely is to have a complete separation of the data. Don’t intermix rows or store anything in the same table (or preferably database).
I would create a client-specific database and give each external system only access to that database.
Do you have a requirement to combine the data at some point? If so, you would lose key integrity, since you would have the same PKs (mostly) in each database table.
If you do need to combine the data, and a multi-column key is not an option, then an updateable view is really your only option so that you can keep that integrity.