数据库查询应该在哪里？

Question

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

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

Answer 1

我曾经在存储过程解决方案方面做得很好但是在去年改变了我的调整，因为数据库变得更快并且ORM已进入主流。存储过程肯定有一个地方。但是当谈到简单的CRUD sql：一个衬垫插入/更新/选择/删除，使用ORM来处理这个是我认为最优雅的解决方案，但我相信很多人会争论另一种方式。 ORM将使用SQL和DB连接构建代码，并使持久性逻辑与您的应用程序更加流畅地集成。

Answer 2

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

祝你好运！

Answer 3

这取决于/它的情境。支持和反对任何一种选择都有很强的论据。就个人而言，我真的不喜欢看到业务逻辑在数据库（在存储过程中）和代码之间分裂，所以我通常希望尽可能在代码中进行所有查询。

在Microsoft世界中，像Reporting Services这样的东西可以从类/对象中检索数据，而不是（以及除数据库/存储过程之外）。此外，像Linq这样的东西可以在代码中为您提供更强类型的查询。还有像NHibernate这样强大，成熟的ORM，允许从代码中编写几乎所有类型的查询。

也就是说，有时您使用查询执行“rowset”类型的操作，这些查询在存储过程中比在代码中工作时要好得多。

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

Answer 4

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

我发现应用程序员通常不会考虑数据库处理信息的最佳方式，因为他们专注于应用程序而不是后端。通过将数据库的代码放在它所属的数据库中，数据库专家可以更好地查看和查看数据库，并考虑数据库及其性能。我们在此支持数百个数据库和应用程序。我可以查看任何数据库，并找到我需要在某些事情发生时找到的代码。我不必为每个数百种不同的应用程序上传应用程序代码，只是为了查看我需要完成工作的部分。