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，你为什么关心？有报告编写工具（Crystal Reports），可以处理很多这方面的工作。

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

通过锁定数据库访问权限，您永远不会进入企业市场。

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

如果您可以使报告功能暂停系统，则可以继续。

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

Answer 7

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

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

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