Mysql 复杂查询的视图或存储过程？

我有一个带有多个（嵌套）子查询的比较复杂的查询，我想让应用程序开发人员可以使用它。该查询是通用的，并生成一个包含数据集集合上的计算值的视图，开发人员只需要查询返回的部分记录（即，它们将限制某些实体ID或日期范围等的结果）

我可以看到3种实现方法：

让开发人员将查询嵌入到每个应用程序中，并根据需要添加自己的

WHERE

子句

创建一个存储过程，该过程接受我期望开发人员需要的所有条件作为参数（为了参数起见，假设我可以预测在可预见的未来需要什么），该过程将运行复杂查询，并根据传递的参数对其进行过滤

将查询实现为具有多个子视图的视图（因为MySQL不允许在视图中进行子查询），并让开发人员将其用作表，并使用

WHERE

让每个应用程序应用所需的过滤器。目前我正在研究3个附加的子视图，主要是因为一些子查询被多次使用，并且作为子视图执行它们可以防止重复-否则情况可能会更糟；-） 在性能方面，什么会更好？（假设所有索引在所有情况下都是等效的）如果可能的话，选择最坏的情况

---

在代码维护方面，您认为什么更好？

如果实施得当，这三种解决方案中的任何一种都适合维护，但请记住在迁移过程（代码或数据库迁移）中如何处理它们

如果查询很大，存储过程将为您提供一点额外的性能，因为它发送的查询较小，因此带宽开销较小。您还可以使用此解决方案获得一点额外的安全性

对于manteinance解决方案，我更喜欢第一个和第二个解决方案，因为您可以在不更改数据库的情况下对查询进行任何更改。如果您选择第一个解决方案，我会将查询调用包装在一个函数中，这样您就只有一个地方可以进行更改

从开发者的角度来看，我会选择视图解决方案，因为它是最透明的解决方案，我的意思是它就像只查询一个常规表，您可以使用descripe命令检查表结构，或者只选择需要查询的字段和条件，或者与另一个表连接，等等

关于where子句灵活性，您可以使用任何建议的解决方案来实现它。您可以在包装函数（1）中添加where参数，也可以在存储过程中添加where参数，但要注意注入（2），或者开发人员可以像往常一样在视图（3）中添加where子句

请记住，在MySQL视图中不是临时表，如果查询非常复杂如果查询被大量使用并以不同的方式使用（禁用缓存性能提升），那么这种解决方案就不是最好的<强> >我会考虑一个临时表<强>解决方案（计数器表），用编程的任务/ CRON（例如，一天、一周、每当需要）更新每个时间段，或者通过设置支持触发器来更新。此解决方案可以大大提高性能

---

希望这能有所帮助，我最喜欢视图解决方案，但从数据库的角度来看，它可能更复杂。

我喜欢定义“好”的问题-您特别询问了性能和可维护性，这让答案可以讨论这种权衡

从性能的角度来看，我不认为这三个选项之间有什么区别，只要查询和数据符合您的预期场景。我会使用100倍以上的数据进行测试，并可能扩展“where”子句以查看发生了什么，但是索引结构等更可能影响性能，而不是从存储过程、视图或客户端应用程序执行相同的SQL

回答这个问题的最好方法是测试它——当然，有许多具体细节可能会使我们飞越者给出的“我希望x、y或z”的一般答案无效。如果性能是一个关键问题，请使用数据库填充工具（Redgate make on，我以前使用过DBMonster）并尝试所有3个选项

从维护的角度来看，我会提供一个选项4，在我看来，这是迄今为止最好的

选项4：构建一个数据访问库，它封装了对数据的访问。让库公开方法和参数以优化记录的选择。考虑使用规范模式（http://en.wikipedia.org/wiki/Specification_pattern). 使用库中最好的查询，不要为实现细节而打扰开发人员

如果这不起作用-异构应用程序代码，对于一个简单的需求来说更改太多-我将评估以下选项：

嵌入式SQL：根据此SQL的重复使用次数，这可能是正常的。如果只有一部分代码运行SQL，那么它在逻辑上类似于数据访问库。但是，如果同一个代码段需要在很多地方重复使用，那么它很可能是bug的来源——SQL中的一个小改动需要在多个地方重复

存储过程：出于维护的原因，我通常不喜欢存储过程——它们往往会因过载而变得脆弱，并创建一种过程思维方式。例如，如果在单独的存储过程中使用此SQL计算还有其他要求，那么很快就会得到一个过程编程模型，存储过程会相互调用

观点：这可能是