我有一个结构如下的表：
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 | ...
以及一些需要访问该表以读取数据并在进程的和处写回一个值的外部系统。
问题是，每个外部系统将只能访问与他的项目相关的数据，即：
- 系统1->ProjectID=2
- 系统2->ProjectID=3
- 系统3->ProjectID=1
我想将这些数据分开以避免错误，因为这些系统将从我们的应用程序外部开发，我不能假设他们只使用自己的数据。
我遇到了两个解决方案：
- 在不同的DB架构中为每个ProjectID创建一个表，并只向每个外部系统提供访问其表的凭据
- 为每个ProjectID创建一个可更新的视图，该视图仅提取特定项目的数据，并仅向每个外部系统提供访问其视图的凭据
还有其他想法吗？
谢谢！
因此，如果我关于API的另一个答案对您不起作用，那么安全处理此问题的适当方法是对数据进行完全分离。不要在同一个表（最好是数据库）中混合行或存储任何内容。
我会创建一个特定于客户端的数据库，并只允许每个外部系统访问该数据库。
您是否有在某个时刻组合数据的要求？如果是这样，您将失去密钥完整性，因为在每个数据库表中都会有相同的PK（大部分）。
如果您确实需要组合数据，而多列键不是一个选项，那么可更新视图实际上是您唯一的选项，这样您就可以保持完整性。
如果有多个项目与数据库交互，您确实需要开发一个API来完成与数据库的所有交互。保持理智、睡眠计划和数据完整性。不要在数据库层中解决此问题。
只是一些良心流。。。
我也在为类似的问题而挣扎。我目前的解决方案是，我有一组表，但每条记录都有一列引用OrganizationID。然后，我的外部程序会附加到SQL Select。。。哪里以及User.OrganizationID=表。组织ID。
当一个人，即父组织的负责人，查看数据时，我不会附加sql，这样他们就可以看到数据，因为它跨越了所有子组织。
这个解决方案与可更新视图没有太大区别（除了我有一个应用程序来处理它）。我也在寻找一个更好的解决方案，因为我的一些数据可能跨越几个组织，这些组织应该相互交互数据（例如，项目1和项目2可以相互交互数据，但项目3是孤立的，项目4可以看到所有数据）