SQL给最终用户：利弊[关闭]

Question

曾几何时，远在遥远的星系中，我见证了几位开发者之间的讨论。 主题是，如果给最终用户访问生产SQL服务器（MS SQL 2008）是个好主意，以便让他们能够根据自己的数据制作自己的报告。

这是商界人士的要求 - “我们的客户希望制作自定义报告”。

提出这个问题的人声称：

1. 他能够通过一组权限为用户提供“只读访问权限”，并使系统绝对安全。
2. SQL最初是一种“最终用户”语言，现在可能就是这样。
3. 拥有运行SQL查询的权限，用户将能够做他们想要的不干扰开发人员和支持。

其他反对此声称的人声称：

1. 崩溃的MS SQL很容易崩溃。 禁止进入。
2. 无论如何，向最终用户公开SQL和数据库结构并不是一个好主意; 这是一个糟糕的设计。
3. SQL对于非程序员来说太复杂了，因此，它不会让他们的生活更轻松。

您如何看待最终用户访问SQL？

先感谢您！

Answer 1

您不仅可以将用户限制为只读访问权限，还可以通过启用查询调控器成本限制来使某些事情更安全。 这将尝试在运行查询之前对查询进行一些成本分析，如果它们超过预定义的阈值，它将拒绝运行它们。

比这更好的是有一个可用于查询的克隆数据库。 这可能就像运行生产系统备份的单独服务器一样简单。 根据您的数据需要“实时”的方式，您可以相应地调整备份/恢复间隔。

至于将数据库暴露给直接查询非程序员是否是一个好主意，这仍然取决于用户是多么精明。 他们可以教SQL吗？ 简单的事情真的不是那么难。

Answer 2

这完全取决于您的用户。 如果用户具有技术能力或对开发此技能集感兴趣，他们可以减轻程序员的大部分工作量。

另一方面，我知道永远不会理解规范化数据结构的骨头，并且它们的失控查询反复崩溃了服务器。

如果您决定使用它，请创建一个单独的数据库镜像以进行报告（如果可能）。 每晚更新，以便他们拥有相当新的数据。 当然，如果他们有实时报告需求，这并不理想。

Answer 3

反对的论点非常薄弱。 如果用户，不能写sql，你为什么关心？ 有报告编写工具（Crystal Reports），可以处理很多这方面的工作。

一些使用其他软件的公司的工作人员知道如何查询数据库，或者他们可以聘请顾问。

你永远不会锁定数据库访问进入企业市场。

编辑：可以在数据库中构建一组视图，以满足大多数用户需求。 这样他们就不必担心复杂的连接。

Answer 4

使最终用户能够访问生产数据库（即使是只读访问权限）编写自己的查询的主要问题是，您的性能会下降到底层并进入子地下室。 如果最终用户可以编写SQL，他们通常不能很好地编写它。 在某些时候，它会发现游标（如果在MS SQL中）和/或他们会过度思考他们的联接。 他们会拉进他们能找到的每张桌子。 如果你想让他们感到满意，可以在另一台机器（或限制良好的VM）上进行非生产数据库的夜间转储，并告诉他们自己解决问题。 专业提示：也告诉他们你没有时间支持它。

我不是反终端用户，我只是认为他们不会被信任以类似于有效方式编写查询。 如果您选择的少数人认为可以信任，请与他们一起试用，如果他们共享密码则将其锁定。

Answer 5

这取决于部署后谁负责产品。 如果情况很明确（你在没有支持的情况下销售代码）那么为什么不呢？ 那不是你的问题。

在您需要处理所有事情并负责正常运行时间的情况下，即使是只读，我也不建议这样做。

Answer 6

您可以使数据库帐户安全，以防止不必要的更改，但您无法确保安全性，以防止出现性能问题。 最终用户可以轻松创建一个查询，锁定所有表并运行很长时间。 它实际上不会使数据库崩溃，但用户会在崩溃时遇到它。

如果您可以使报告功能可能挂起系统，您可以继续。

但是，我必须说我怀疑这是否有用。 与统计数据一样，您必须知道您要求的正是您想要的，否则结果将毫无用处。

Answer 7

最终，在实现最终用户数据分析方面具有商业价值。 通过SQL直接访问是一种方法。

尚未提及一个缺点。 默认情况下，SQL Server中的读者会阻止编写者。 这意味着您可能需要启用快照隔离（或者可能使用数据库快照或数据库的只读副本），否则即使是最简单，最无辜的用户查询也可能会削弱您的生产系统。

也许令人惊讶的是，尽管微软在7年前引入了快照隔离模式，但看到系统在关闭后仍然投入生产似乎很常见（默认情况下是没有SI的READ COMMITTED）。 因此，在允许用户访问您的生产系统之前，您可能需要进行更改并进行一些重新测试和重构。