我认为造成这种困难的原因是：

" 我们已经在包含所有CV's + columns + users限制的配置表上设置了Dynamic SQL AP。"

存在分析特权，可以根据应用程序域来控制用户对特定数据的访问。 例如。 该功能旨在支持诸如"用户组REGIONNORTH中的用户只能访问与区域'north'相关的数据"之类的限制。
简而言之，它旨在在抽象级别上工作。

相反，您所描述的方法是将数据模型实现的每个元素组合成一种笛卡尔积的结果。
这本身不会导致主要问题 似乎您要为所有用户的每个简历中的每一列创建一个单独的AP。

这不是您要管理用户权限的方式，对吗？
相反，您希望像上面的示例一样具有这种权限。
适用于所有CV且基于您的应用程序数据模型的事物。
您希望权限与您的应用程序有关。

已经说了这么多，但没有理由为什么每个CV都需要它自己的AP和过程。 完全有可能为多个CV分配相同的AP +过程-实际上，这就是"正常"/预期的用例。

您还写道：" 当前，由于结构不同，我们需要为每个CV设置1个AP和1个存储过程。"- 它可以指示两件事：

1。 CV实际上确实是彼此完全独立的，处理不相关的概念和数据，并且与任何其他CV没有关系。
或
2。 简历涉及相同的一般主题（模型领域），但涵盖不同的方面。 但是，例如，"区域"是所有CV中的"区域"。

如果您实际上是在场景1中工作（不太可能），那么您实际上是在处理许多独立的数据库，而首先尝试共享AP代码并不是一个好主意。

如果您确实在方案2中工作，则可以为许多视图共享AP，还可以利用视图层次结构中的AP在查询时自动组合的事实。

要回答 直接提出问题，没有任何选择让SP在运行时知道哪个AP或CV触发了执行。 这是有道理的，因为您不想创建"一站式授权"过程-它将很快变成无法维护的混乱。

嗨，拉斯，

我了解您的要点。 感谢您详细了解。

肯定会考虑到这一点。

最好的问候

或者。