作为查询的存储过程:CallableStatement 与PreparedStatement
PostgreSQL 文档 建议使用CallableStatement
调用存储过程。
对于返回行集的存储过程,使用 CallableStatement 之间有什么区别:
String callString = "{ call rankFoos(?, ?) }";
CallableStatement callableStatement = con.prepareCall(callString);
callableStatement.setString(1, fooCategory);
callableStatement.setInt(2, minimumRank);
ResultSet results = statement.executeQuery();
和使用常规 PreparedStatement
:
String queryString = "SELECT FooUID, Rank FROM rankFoos(?, ?);";
PreparedStatement preparedStatement = connection.prepareStatement(queryString);
preparedStatement.setString(1, fooCategory);
preparedStatement.setInt(2, minimumRank);
ResultSet results = statement.executeQuery();
据我了解,CallableStatement
提供了一种与语言无关的调用存储过程的方式。但这对我来说并不重要,因为我知道我正在使用 PostgreSQL。据我所知,使用 PreparedStatement
的明显优势是更通用的查询,将存储过程视为一个表,我可以在其上使用 WHERE
, < code>JOIN、ORDER BY
等。
我缺少的方法之间是否存在某些方面或差异?如果使用存储过程作为查询,建议使用哪种存储过程?
PostgreSQL documentation recommends using a CallableStatement
to call stored procedures.
In the case of a stored procedure that returns a rowset, what are the differences between using CallableStatement
:
String callString = "{ call rankFoos(?, ?) }";
CallableStatement callableStatement = con.prepareCall(callString);
callableStatement.setString(1, fooCategory);
callableStatement.setInt(2, minimumRank);
ResultSet results = statement.executeQuery();
And using a regular PreparedStatement
:
String queryString = "SELECT FooUID, Rank FROM rankFoos(?, ?);";
PreparedStatement preparedStatement = connection.prepareStatement(queryString);
preparedStatement.setString(1, fooCategory);
preparedStatement.setInt(2, minimumRank);
ResultSet results = statement.executeQuery();
As I understand, CallableStatement
offers a language-agnostic way of calling stored procedures. This doesn't matter to me though, since I know I'm using PostgreSQL. As far as I can see, the obvious advantage of using the PreparedStatement
is a more versatile query, treating the stored procedure as a table, on which I can use WHERE
, JOIN
, ORDER BY
, etc.
Are there aspects or differences between the methods that I'm missing? In the case of a stored procedure used as a query, which is recommended?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我很确定第二种方法与某些RDBMS完全无法使用,但是由于您只想使用PostgreSQL,所以这并不重要。对于您的简单情况,确实没有太大的缺点。我可以看到两个问题弹出:
取决于存储过程的编写方式,它们可能要求您注册参数以执行该过程。通过准备好的陈述,这根本不可能。如果您同时控制了存储过程的创建和调用代码,则可能不必担心。
首先,它限制了调用存储程序的有效性。存储过程的主要优点之一是将查询逻辑封装在数据库级别。这使您可以调整查询或在某些情况下添加功能,而不必更改代码。如果您打算添加子句加入存储过程调用结果的位置,为什么不将原始查询放入Java层?
I'm pretty sure the second approach does not work at all with some RDBMS's, but since you are only going to use PostgreSQL, that shouldn't matter too much. For your simple case, there really isn't much of a downside. There are two issues I can see popping up:
Depending on how the stored procedures are written, they may require you to register out parameters in order to execute the procedure. That's not going to be possible at all with prepared statements. If you control both the creation of the stored procedure and the calling code, you probably don't have to worry about this.
It limits the effectiveness of calling stored procedures in the first place. One of the main advantages of a stored procedure is to encapsulate the querying logic at the database level. This allows you to tune the query or in some cases add functionality without having to make changes to your code. If you're planning on adding where clauses joins to the results of the stored procedure call, why not just put the original query in your java layer?
主要区别是独立和封装的编程方式。
想象一下,您是Java程序员,您不知道如何使用数据库,以这种方式,您无法使用第二种方法,并且您将以第二种方式遇到问题。
第一种方法使您可以执行Java代码,并要求某人为您编写Quires作为存储过程,以便您可以轻松使用它们。
我同意@dlawrence
The main difference is independence and encapsulated way of programming.
Imagine that you are a Java Programmer and you don't know how to use Database, in this way you can not use the second method and u will meet problems in the second way.
First method allows you to do your java code, and ask somebody to write the quires for you as Stored-Procedure, so u can use them easily.
I do agree with @dlawrence