数据库查询应该在哪里存在？

Question

查询是否应该存在于需要数据的类中？查询应该存在于数据库中的存储过程中，以便它们可重用？

在第一种情况下，更改查询不会影响其他人（其他代码或生成报告的人员等）。在第二种情况下，查询可以被许多人重复使用，只存在于一个地方，但如果有人打破了这些查询，那么他们就会被打破。

Answer 1

我曾经在存储过程解决方案方面做得很大，但是由于数据库变得更快而ORM已经进入主流，所以在去年改变了我的调。存储过程当然有一个地方。但是当涉及到简单的CRUD sql时：一个插入/更新/选择/删除，使用ORM来处理这是我认为最优雅的解决方案，但我相信很多人会反其道而行。 ORM将把SQL和数据库连接建立在代码之外，并使持久性逻辑更加流畅地与应用程序集成。

Answer 2

我建议将它们作为存储过程放在数据库中。您不仅可以获得重用优势，还可以确保相同的查询（作为选择，更新，插入等），因为您使用的存储过程相同。如果你需要改变它，你只能在一个地方改变它。此外，您将利用数据库服务器的处理能力而不是应用程序所在的服务器/计算机。这是我的建议。

祝你好运！

Answer 3

这取决于它的情况。对于这两种选择都有非常强烈的争论和反对意见。就个人而言，我真的不喜欢看到业务逻辑在数据库（在存储过程中）和代码中分离，所以我通常希望尽可能在代码中进行所有查询。

在微软的世界里，有些东西像Reporting Services可以从类/对象中检索数据，而不是数据库/存储过程（除了数据库/存储过程）。此外，还有像Linq这样的代码给你更强大的类型查询。还有像NHibernate这样的强大，成熟的ORM，可以用来编写几乎所有类型的代码查询。

也就是说，有些时候您正在使用查询的“行集”类型的事物在存储过程中比在代码中工作得更好。

在大多数情况下，两个选项都可以正常工作。

Answer 4

从我的角度来看，我认为存储过程是最好的选择。首先，它们更容易维护，只需要运行脚本而不是重新编译应用程序即可快速更改。其次，它们对安全性要好得多。您可以在sp级别设置权限，而不是直接在表和视图上设置权限。这有助于防止欺诈，因为用户不能直接对存储过程中未指定的数据库执行任何操作。他们更容易表现调整。当您使用存储的特效时，可以使用数据库依赖关系元数据来帮助确定数据库更改对代码库的影响。在许多系统中，并不是所有的数据访问或甚至是CRUD操作都会通过应用程序进行，因为在我看来，代码会适得其反。如果所有的数据访问都在一个地方（我支持的想法），它应该在数据库中，所有可能需要使用它的应用程序或进程都可以访问它。

我发现应用程序员通常不会考虑数据库处理信息的最佳方式，因为他们专注于应用程序而不是后端。通过将数据库的代码放入数据库所在的位置，数据库专家可以更好地查看和审查数据库，这些专家会考虑数据库及其性能。我们在此支持数百个数据库和应用程序。我可以查看任何数据库，并查找当某些内容很慢时我需要查找的代码。我不必上传数百个不同应用程序中的每一个应用程序代码，只是为了查看我需要做的工作。