面向最终用户的 SQL：优点和缺点 [关闭]

Question

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

这是来自商务人士的要求——“我们的客户想要制作自定义报告”。

一个提出这个建议的人声称：

1. 他能够通过一组 权限并使系统绝对安全。
2. SQL 最初 是一种“最终用户”语言，现在可能如此。
3. 拥有权限 运行 SQL 查询，用户将能够做他们不想做的事情 令人不安的开发人员和支持人员。

其他反对的人声称：

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

您如何看待授予最终用户访问 SQL 的权限？

提前谢谢你！

Answer 1

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

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

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

Answer 2

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

另一方面，我知道一些笨蛋永远不会理解规范化的数据结构，而且他们失控的查询一再导致服务器崩溃。

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

Answer 3

让最终用户有权针对生产数据库编写自己的查询（即使具有只读访问权限）的主要问题是，您的性能会下降到地下室。如果最终用户可以编写 SQL，他们通常不会写得很好。在某些时候，他们会发现游标（如果在 MS SQL 中）和/或他们会过度思考他们的连接。他们会找到他们能找到的每张桌子。如果您想让他们开心，请每晚将数据转储到另一台机器（或受限虚拟机）上的非生产数据库中，并告诉他们不要自暴自弃。专业提示：同时告诉他们你没有时间支持它。

我不是反最终用户，我只是认为他们不值得信任以任何类似有效的方式编写查询。如果您有一些您认为可以信任的人，请与他们一起尝试，如果他们共享密码，则将其锁定。

Answer 4

这取决于部署后由谁负责产品。 如果情况很清楚（您在没有支持的情况下出售所有代码）那为什么不呢？ 那就不是你的问题了。

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

Answer 5

您可以使数据库帐户免受不必要的更改，但不能使其免受性能问题的影响。最终用户可以轻松创建一个锁定所有表并长时间运行的查询。它实际上不会使数据库崩溃，但用户会经历崩溃。

如果您对可能导致系统挂起的报告功能没问题，您可以继续。

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

Answer 6

反对的论点非常微弱。如果用户，不能写sql，你为什么在乎？有报告编写工具（Crystal Reports）可以处理很多事情。

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

你永远不会在数据库访问被锁定的情况下进入企业市场。

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

Answer 7

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

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

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