SQL 报告使用存储过程或 query/view
SQL Reporting Use stored proc or query/view
我是软件开发人员，不是 TSQL 或 DBA 专家，只是背景知识。我的一个应用程序使用 SQL 视图的分配用于报告目的，在这个阶段（可能会改变）windows 应用程序执行视图并且我在 grid/table 中显示数据用于报告目的。视图变得越来越复杂和缓慢，这是一个问题。我正在重新设计应用程序以使用 Web 前端进行报告。但我的问题是，就 SQL 而言，报告的最佳方法是什么？我的报告应该基于存储过程还是视图？欢迎对 SQL 报告提出任何其他意见或建议，就像我提到的我是一名软件开发人员，我尽量远离 SQL 工作，但这已经成为一个问题，我认为这是一个很好的是时候磨练我的 SQL 知识了。
感谢阅读。
存储过程 (SP) 是比视图更好的选择，但视图比嵌入在报表中的 SQL 查询要好得多。我知道你没有提到嵌入式 SQL 但我将简要讨论它以给出更全面的答案。
当您将 SQL 查询嵌入到报表（或应用程序或数据库之外的任何内容）中时，您假设所有引用的对象都不会以任何方式更改。这首先是一个很大的假设（假设是错误的），其次是对数据库所有者的严重限制 - 他们不能改变任何东西，因为它可能会破坏某些地方。
当您使用 SP 或视图访问数据库时，您做出了合理的假设，即您正在调用的对象（SP 或视图）的名称不会改变，并且任何参数集都将保持不变或至少保持兼容。这两种方法都对调用者隐藏了查询逻辑——逻辑可以随着时间的推移得到纠正和改进，而不会影响调用者。整个数据库都可以重构甚至重新设计，只要公开对象的名称（和任何参数）保持不变，调用者永远不会知道。
与视图相比，使用 SP 的优势在于您可以做更多的事情。例如，验证参数值是否在预期范围内是个好主意。如果您有一个特别复杂的查询，您可以将其分解成更小的步骤，例如使用临时表。继续进行非常繁重的查询，您甚至可以在 SP 中执行临时维护步骤，例如更新统计信息。
我建议对所有数据库访问使用 SP。你可能 不需要 到现在，但它会给你更多的空间来改变未来的东西 如果 你需要。
我是软件开发人员，不是 TSQL 或 DBA 专家，只是背景知识。我的一个应用程序使用 SQL 视图的分配用于报告目的，在这个阶段（可能会改变）windows 应用程序执行视图并且我在 grid/table 中显示数据用于报告目的。视图变得越来越复杂和缓慢，这是一个问题。我正在重新设计应用程序以使用 Web 前端进行报告。但我的问题是，就 SQL 而言，报告的最佳方法是什么？我的报告应该基于存储过程还是视图？欢迎对 SQL 报告提出任何其他意见或建议，就像我提到的我是一名软件开发人员，我尽量远离 SQL 工作，但这已经成为一个问题，我认为这是一个很好的是时候磨练我的 SQL 知识了。
感谢阅读。
存储过程 (SP) 是比视图更好的选择，但视图比嵌入在报表中的 SQL 查询要好得多。我知道你没有提到嵌入式 SQL 但我将简要讨论它以给出更全面的答案。
当您将 SQL 查询嵌入到报表（或应用程序或数据库之外的任何内容）中时，您假设所有引用的对象都不会以任何方式更改。这首先是一个很大的假设（假设是错误的），其次是对数据库所有者的严重限制 - 他们不能改变任何东西，因为它可能会破坏某些地方。
当您使用 SP 或视图访问数据库时，您做出了合理的假设，即您正在调用的对象（SP 或视图）的名称不会改变，并且任何参数集都将保持不变或至少保持兼容。这两种方法都对调用者隐藏了查询逻辑——逻辑可以随着时间的推移得到纠正和改进，而不会影响调用者。整个数据库都可以重构甚至重新设计，只要公开对象的名称（和任何参数）保持不变，调用者永远不会知道。
与视图相比，使用 SP 的优势在于您可以做更多的事情。例如，验证参数值是否在预期范围内是个好主意。如果您有一个特别复杂的查询，您可以将其分解成更小的步骤，例如使用临时表。继续进行非常繁重的查询，您甚至可以在 SP 中执行临时维护步骤，例如更新统计信息。
我建议对所有数据库访问使用 SP。你可能 不需要 到现在，但它会给你更多的空间来改变未来的东西 如果 你需要。