不

数据库模式的保护是一种隐蔽的安全性。

您的软件的设计和配置方式应确保在黑客了解其设计时不会损害其安全性。事实上，在最好的情况下，您的设计是公开的，以便安全专业人员可以对其进行批评，并且您可以不断改进它。

@John-Wu 的答案是正确的，不应将架构保护置于数据保护之上。

数据是最重要的，是攻击者的妥协目标。Schema 充其量只是信息泄漏。

也就是说，数据库本身通常以与数据不同且更高的特权级别来处理模式元数据，这并非没有道理。正如@marcus-muller 所说，模式为攻击者提供了有用的提示。拥有查看架构权限的用户几乎总是可以查看数据，而拥有查看数据权限的用户可能无法查看架构。

因此，不应将模式视为不必要的保护。但数据最重要。

尽管我同意@JohnWu 的回答，即“默默无闻的安全”是一个糟糕的概念，但有一件事：

是的。在某种方式。

复杂的数据库方案通常具有复杂的关系。但让我举一个简单的例子：

你有一张桌子

+----+------------+-------+
| ID | CustomerNo | Order |
+----+------------+-------+
|  0 |          1 |  Nuts |
|  1 |          1 | Bolts |
|  2 |          2 |  Nuts |
|  3 |          1 |  Wire |
+----+------------+-------+

whereID是自增主键，CustomerNo指的是你的customer表的Order主键，指的是你的order表的主键。这样，您可以将订单映射到客户。

当然，您只让每个客户看到“属于”他们自己的行。

不过，你看到问题了吗？

确切地说，通过线性增加的 ID 字段，客户 1 可以轻松地确定竞争对手何时下订单，只需不像“普通”客户那样批量下订单，而是每分钟自动下订单。

这样，他们就知道每周二下午 4 点 30 分是比赛订单。现在，他们非常了解硬件市场，每周二下午 4 点 20 分在市场上大卖期权，从而提高了坚果的市场价格，损害了他们的竞争对手，并且从他们不应该获得的知识中获得了经济利益第一名。

原则上，这是一个数据清洁度的问题。单调的主键为您提供了您不应该拥有的（部分）信息。因此，您的客户 API 需要确保信息泄漏为零。我的意思是在数学上：信息有一个伪单位，位，并且有一个完整的数学学科称为信息论，它描述了基于随机性的某个事件的观察中有多少信息（例如，如果有两个以上表中的客户，您无法知道您的哪个竞争对手在下午 4:30 下订单，但您仍然可以从中获得概率，因此获得非零信息）。

如果客户有权访问数据库方案，您就不太可能向客户隐藏此类信息。事实上，如果您不向他们提供他们可能不应该获得的信息，那么该计划对他们没有帮助。从这个意义上说，您的方案不需要保密，但是您可能仍然只认为客户可访问记录中的“关系”数据实际上应该对客户保密。