曾几何时，在遥远的星系中，我见证了几个开发人员之间的讨论。主题是让最终用户访问生产 SQL 服务器 (MS SQL 2008) 是否是个好主意，以便让他们能够根据自己的数据制作自己的报告。
这是商界人士的要求——“我们的客户想要制作自定义报告”。
一个提出这个建议的人声称：
其他反对这一点的人声称：
您如何看待授予最终用户访问 SQL 的权限？
先感谢您！
您不仅可以通过将用户限制为只读访问，还可以通过打开查询调控器成本限制来使某些事情更安全。这将尝试在运行查询之前对查询进行一些成本分析，如果它们超过预定义的阈值，它将拒绝运行它们。
比这更好的是有一个可用于查询的克隆数据库。这可能很简单，就像运行生产系统备份的单独服务器一样简单。根据您的数据需要的“实时”程度，您可以相应地调整备份/恢复间隔。
至于将数据库公开给非程序员直接查询是否是一个好主意，这仍然取决于用户的精明程度。可以教他们 SQL 吗？对于简单的事情真的没有那么难。
这完全取决于您的用户。如果用户有技术能力或有兴趣开发此技能集，他们可以减轻程序员的大部分工作量。
另一方面，我知道那些永远不会理解规范化数据结构的傻瓜，他们失控的查询一再导致服务器崩溃。
如果您决定这样做，请尽可能创建一个单独的数据库镜像用于报告。每晚更新一次，以便他们拥有相当最新的数据。当然，如果他们有实时报告需求，这并不理想。
反对的论据非常微弱。如果用户，不能写sql，你为什么在乎？有报告编写工具（Crystal Reports）可以处理很多事情。
一些使用其他软件的公司的员工确实知道如何查询数据库，或者他们可以聘请顾问。
锁定数据库访问权限，您将永远无法进入企业市场。
编辑：可以将一组视图内置到数据库中，以满足大多数用户的需求。这样他们就不必担心复杂的连接。
授予最终用户访问权限以针对生产数据库编写自己的查询（即使具有只读访问权限）的主要问题是，您的性能将下降到底层并进入地下室。如果最终用户可以编写 SQL，他们通常不会写得很好。在某些时候，他们会发现游标（如果在 MS SQL 中）和/或他们会过度思考他们的连接。他们会找到他们能找到的每张桌子。如果您想让他们开心，请每晚将数据转储到另一台机器（或受限虚拟机）上的非生产数据库中，并告诉他们不要自暴自弃。专业提示：还告诉他们您将没有时间支持它。
我不是反最终用户，我只是不认为他们可以被信任以任何类似有效的方式编写查询。如果您有少数几个您认为可以信任的人，请与他们一起尝试，如果他们共享密码，则将其锁定。
这取决于部署后谁负责产品。如果情况很清楚（您在没有支持的情况下出售所有代码）那为什么不呢？那不是你的问题。
在您必须照顾所有事情并负责正常运行时间的情况下，即使是只读的，我也不建议这样做。
您可以使数据库帐户免受不必要的更改，但不能使其免受性能问题的影响。最终用户可以轻松创建一个锁定所有表并长时间运行的查询。它实际上不会使数据库崩溃，但用户会将其视为崩溃。
如果您对可能挂起系统的报告功能没问题，您可以继续。
但是，我必须说我怀疑这个的用处。与统计数据一样，您必须知道您所要求的正是您想要要求的，否则结果将毫无用处。
最终，最终用户对数据进行分析具有商业价值。通过 SQL 直接访问是一种方法。
一个缺点还没有提到。默认情况下，SQL Server 中的读取器会阻止写入器。这意味着您可能需要启用快照隔离（或者可能使用数据库快照或数据库的只读副本），否则即使是最简单、最无辜的用户查询也可能会削弱您的生产系统。
也许令人惊讶的是，尽管微软在 7 年前引入了快照隔离模式，但在关闭它的情况下投入生产似乎仍然很常见（默认为 READ COMMITTED without SI）。因此，在允许用户访问您的生产系统之前，您可能需要进行更改并进行一些重新测试和重构。