column 是一个 SQL*Plus 命令。它在 SQL 或 PL/SQL 中无效,因此您不能在 Java 应用程序中使用它。
像 &v_firstname 这样的替换变量也是一个 SQL*Plus 构造——它们在 SQL 或 PL/SQL 中无效,因此您不能在 Java 应用程序中使用它们。
如果您的目标是在单个查询中从 tbcustomer 获取 firstname 以及从 tbwork 获取所有列,则需要连接这两个表。假设两个表都有一个customer_id 列,这就是这两个表应该如何连接
SELECT cust.firstname,
work.*
FROM tbcustomer cust
JOIN tbwork work ON (cust.customer_id = work.customer_id)
WHERE cust.customer_id = 111
假设您将针对多个 customer_id 值执行此查询,但是,111 应该是绑定变量而不是文字,并且您的 Java 代码应该使用 PreparedStatement 来准备 SQL 语句,然后绑定在执行查询之前使用setInt 方法获取类似 111 的值。
如果你想把它分成两个数据库调用,你可以简单地做类似的事情
PreparedStatement stmtGetFirstName = connection.prepareStatement("select firstname from tbcustomer where customer_id = ?");
stmtGetFirstName.setInt( 1, 111 );
ResultSet rsGetFirstName = stmtGetFirstName.executeQuery();
String firstName = rsGetFirstName.getString();
PreparedStatement stmtGetWork = connection.prepareStatement("select ?, work.* from tbwork where customer_id = ?");
stmtGetWork.setString( 1, firstName );
stmtGetWork.setInt( 2, 111 );
ResultSet rsGetWork = stmtGetWork.executeQuery();
如果您可以保证所有 6 亿次执行都将发生在同一个数据库会话中,那么您可以使用数据库上下文。您需要创建上下文和它在数据库中使用的包
SQL> create or replace context fname_ctx using scott.pkg_get_fname;
Context created.
SQL> ed
Wrote file afiedt.buf
1 create or replace package pkg_get_fname
2 is
3 procedure set_fname( p_customer_id in number );
4 function get_fname return varchar2;
5* end;
SQL> /
Package created.
SQL> create or replace package body pkg_get_fname
2 is
3 procedure set_fname( p_customer_id in number )
4 as
5 begin
-- Obviously, you'd get the data here from your table rather than hard-coding 'Bob'
6 dbms_session.set_context( 'fname_ctx', 'fname', 'Bob' );
7 end;
8
9 function get_fname
10 return varchar2
11 is
12 l_fname varchar2(100);
13 begin
14 l_fname := sys_context( 'fname_ctx', 'fname' );
15 return l_fname;
16 end;
17 end;
18 /
Package body created.
然后,您可以在 Java 中调用 pkg_get_fname.set_fname(111) 来设置上下文并在查询中使用函数 pkg_get_fname.get_fname。
然而,关注性能并计划从 Java 对数据库执行 6 亿次查询似乎很奇怪。这将涉及中间层和数据库服务器之间的大量网络往返——如果你真的关心性能,你会将这项工作推送到数据库中的存储过程以消除网络循环——旅行。而且您多次执行它们的事实使我怀疑您正在进行大量的逐行处理,而不是让数据库进行基于集合的操作。这也将成为业绩不佳的主要原因。此外,数据库生来就是为了连接,因此假设有适当的索引,像这样的简单连接会显着增加查询成本是很不寻常的。