将我的Web应用程序的常见SQL查询存储在数据库中以供执行时，是否会被认为是疯狂的？或者这是常见的做法？或者这是不可能的？
我的想法是，这样，我避免将SQL硬编码到我的应用程序文件中，并添加另一个抽象级别。
这是疯了吗？这是一个存储过程是什么？或者那是别的吗？编辑：以下答案作为“存储过程”的背景非常有用，但没有回答我的核心问题：当我有一个包含可以调用的查询的数据库表时，是一个“存储过程”吗？即，像这样的东西
INDEX | NAME | QUERY
1 | show_names | "SELECT names.first, names.last FROM names;"
2 | show_5_cities | "SELECT cities.city FROM cities LIMIT 0,5;"
etc.
还是有一个更复杂的机制包含存储过程的概念？我的例子是人们做的事情的实际例子吗？
答案 0 :(得分：2)
除了MUG4N有关使用存储过程的原因之外，还有三个：
安全
您可以授予对应用程序的访问权限，以执行存储过程，同时拒绝直接访问表。
深入思考防守。如果您的应用程序被破解，那么它们将仅限于执行您定义的过程。这意味着“drop table”之类的内容将被明确禁止，当然，除非您有一个程序来执行此操作。
相反，如果您的应用程序被破解并且您允许该应用程序拥有对您的SQL Server的完全访问权限，那么将会发生以下两种情况之一。您的数据消失和/或破解者很容易得到副本。
单元测试。 如果您可以直接点击它们而不必通过应用程序本身，那么对您的查询进行单元测试要容易得多。
在飞行中的变化： 如果您在发布站点后需要修改查询，那么只进行一次proc更改比重新部署自上次部署后可能已经过其他更改的代码要容易得多。例如，假设您的页面效果不佳。在评估之后，您确定只更改查询的连接将解决此问题。修改过程并继续。
答案 1 :(得分：1)
我认为你应该明确地使用存储过程。这是常见的做法！
使用存储过程只有两个优点：
它们将在所有环境中运行，并且无需重新创建逻辑。由于它们位于数据库服务器上，因此使用的应用程序环境没有区别 - 存储过程保持一致。如果您的设置涉及不同的客户端，不同的编程语言 - 逻辑仍然在一个地方。 Web开发人员通常较少使用此功能，因为Web服务器和数据库服务器通常紧密相关。但是，在复杂的客户端 - 服务器设置中，这是一个很大的优势。一旦客户端更新，客户端就会自动始终与过程逻辑同步。
他们可以减少网络流量。复杂，重复的任务可能需要获得结果，对它们应用一些逻辑，并使用它来获得更多结果。如果只需要在数据库服务器上完成此操作，则无需从应用程序服务器向数据库服务器发送结果集和新查询。网络流量是导致性能问题的常见瓶颈，而存储过程可以帮助减少这种情况。但更常见的是，数据库服务器本身就是瓶颈，因此这可能不是什么好处。
答案 2 :(得分：1)
这个想法肯定有它的吸引力 - 但问题是，它们几乎不可能扩展..我从来没有见过一个可扩展的解决方案来维护存储过程（特别是在MySQL中）并没有让我快门。
由于您似乎正在迈向PHP / MySQL路由，我将举几个例子来说明我在MySQL中存储过程的经验：
答案 3 :(得分：0)
存储过程只是一个或多个“预编译”并存在于数据库内的SQL语句。您可以调用它们来返回一行或多行数据，或者更新，插入或删除数据。
如果您告诉我们您正在使用的Web框架和数据库，我们可以为您提供如何调用存储过程的实际示例，或者至少指向一两篇文章以帮助您前进。
您还可以考虑使用ORM框架，例如Hibernate。这将允许您完全放弃处理SQL代码。我是一名.Net开发人员，所以我不确定你在PHP / MySQL平台上有什么可用，但我确信有很多可供选择。
答案 4 :(得分：-1)
您应该考虑一下，在开发商业级分层应用程序时，数据库背后始终有人使其安全可靠，其他人背后是应用程序逻辑和Web代码背后的其他人，因此您可以获得最佳所有人一起工作。
一旦设计了应用程序，每个人都开始进行实现，db人员会向其他人提供某种使用隐藏SQL的API，开发人员不必考虑它并专注于他们的代码，我曾担任过数据库开发人员并使用一些COM技术来克服应用程序逻辑的扩展和修改或重用，这些产品中的数据库太重要了，不能将其放在野外，因此安全性是一个非常严重的问题。
但在大多数情况下，Web应用程序是由Web开发人员制作的，他们往往没有设计时间，在接近的时间进行大的更改，因此他们不使用存储过程，他们甚至不保证执行或尝试将安全保留给应用程序，使数据库不受保护并容易受到攻击。
如果你正在做所有事情而且经常更换你的产品你应该避免使用它们，因为它会是双重工作而且大部分时间都是无用的，一旦你稳定了你的逻辑，你就可以开始将更重的查询迁移到存储过程