在这个博客中，我将展示一些授予他人视图特权的例子，并解释在什么情况下我们需要"授予选项"。

写这个博客的动机来自这样一个问题：没有足够的特权从数据库视图中选择该线程中的场景有点复杂。我不会在这里详细解释这种情况。如果你有兴趣，可以看看那里。

这里有一个简单的场景/问题，步骤如下。

1。有三个用户A、B、C，每个用户都有自己的模式。用户A在模式A中创建"表A"，并将"表A"上的选择权限授予用户B.

3。用户B在方案B中创建"视图B"，"视图B"基于"表A"。

4。现在问题来了。用户B能否将"视图B"的select权限授予用户C？用户C能从"视图B"中选择数据吗？

为了回答这些问题，我们首先在SAP HANA中进行一些测试。我使用的是SAP HANA SPS 08 Rev。80.

第1步：系统创建三个用户，用户A、用户B和用户C。

第2步：用户A在架构用户A下创建表A，并将该表上的选择权限授予用户B。

第3步：用户B在架构用户B下创建视图B，视图B基于表A。

第4步：用户B尝试将视图B上的选择权限授予用户C，但失败。

那么为什么用户B不能将视图B（自己创建）的选择权限授予用户C？？？

原因很明显。虽然视图\u B是由用户\u B创建的，但是视图\u B是基于表\u A的，用户\u C无权选择该表。想象一下，如果用户\u B成功地执行了grantsql，那么特权将一文不值。用户（例如用户C）可以使用此"变通方法"通过其他人（例如用户B）获得所有内容（例如表A）。

解决方案也非常简单。我们只需要让用户A对用户B说点什么，比如：

"嘿，伙计，你可以自己玩我的篮球（表A），如果你和其他人（用户C）有一个游戏（视图B），你也可以用我的篮球（这意味着你可以让其他人（用户C）在你的游戏（视图B）中触摸我的篮球（表A）"。

希望你能理解好的句子。我花了一些时间来创造它。现在"WITH GRANT OPTION"可以在这里扮演一个角色，它可以让被授予者进一步将特权授予其他人，或者类似于此视图场景中的"级联连接"。所以，让我们试试看。

第5步：用户A使用GRANT选项将表A上的select权限授予用户B。

第6步：用户C可以成功地选择视图B。

现在让我们尝试另一个与Re中的场景类似的例子：在本例中，淘返利，没有足够的权限从数据库视图中选择，我们将让用户A授予select权限首先将表A上的表授予用户C。

步骤1：系统创建三个用户，即用户A、用户B和用户C。

步骤2：用户A在架构用户A下创建表A，并将该表上的选择权限授予用户B和用户C。注意：此步骤中没有WITH GRANT选项。

步骤3：用户B根据表A和用户C在架构用户B下创建视图B将整个架构用户\u B的选择权限授予用户\u C。

步骤4：用户\u C尝试选择视图\u B，但失败。

为什么？？？也许你现在有点困惑了。因为用户A将表A上的select权限授予用户C，所以用户C可以选择表A。这是真的。用户C可以成功运行以下SQL.

2。由于用户\u B将整个架构用户\u B的选择权限授予用户\u C，大数据前景，因此应该启用用户\u C来选择架构用户\u B下的所有内容。但这是真的吗？从错误消息来看，第2点不是真的。但是为什么？？？

我们还是可以用篮球的例子。想象一下如下：

1。用户A对用户B说："嘿，用户B，你可以自己打我的篮球。"

2。用户A对用户C说："嘿，用户C，你可以自己打我的篮球。"

3。用户B对用户C说："嘿，用户C，你可以随时和我一起打篮球。"

如果用户C加入用户B使用自己篮球的游戏，没有问题。但是如果用户B在游戏中使用用户A的篮球，返利app，用户C能加入这个游戏吗？不，因为用户A没有对用户B说"如果你和其他人（用户C）有一个游戏（视图B），你也可以使用我的篮球（这意味着你可以让其他人（用户C）在你的游戏（视图B）中触摸我的篮球（表A））"。这就是原因。希望你也能理解它。

如果你不明白的原因。这是你的另一个理由。如果您仍然认为第4步中不应出现错误，请设想以下情况。

1。如果第4步没有错误，用户\u B将知道用户\u C可以选择表\u A.

2。如果第4步出现错误，用户B会知道用户C无法选择表A.

用户（例如用户B）可以使用此"方法/解决方法"来知道/推断其他用户（例如用户C）的某些权限

但是为什么用户B可以知道/推断这一点？？？用户A告诉他了吗？不。用户有没有告诉他？不。用户C的权限应该是用户B的秘密！！！这就是为什么用户C到目前为止还不能选择视图B。所以，我们仍然需要"WITH GRANT OPTION"来解决这个问题。

第五步：用户A将表A上的选择权限授予带有GRANT OPTION的用户B。

第六步：用户C现在可以成功选择视图B。