java程序查詢綁定變量值,java程序查詢綁定變量值數據

本文目錄一覽：

• 1、誰知道在Java中查詢數據庫後怎麼把查詢的值賦給一個變量啊 用ResultSet類的方法
• 2、如何在Java中獲取環境變量的值
• 3、java程序操作sql報錯 錯誤為： 並非所有變量都已綁定
• 4、jdbc查詢數據庫報：java.sql.SQLException: ORA-01006: 綁定變量不存在
• 5、Java程序員在寫SQL時常犯的錯誤！

誰知道在Java中查詢數據庫後怎麼把查詢的值賦給一個變量啊 用ResultSet類的方法

理論上這樣賦值

User_Money=rst.getString(“Money”);

但你要考慮一下你的數據庫，如果username和Money不是一對一的關係，即一個名字對應三個Money，那麼你sql語句得到的將是值

如果使用下面語句

if(rst.next()){

User_Money=rst.getString(“Money”);//將得到第一個值

}

如果使用下面語句

while(rst.next()){ //有下一個值存在，while循環將繼續，那麼User_Money連續被賦值

User_Money=rst.getString(“Money”);//將得到第三個值

}

如何在Java中獲取環境變量的值

當程序中需要使用與操作系統相關的變量（例如：文件分隔符、換行符）時，Java提供了System類的靜態方法getenv()和getProperty()用於返回系統相關的變量與屬性，getenv方法返回的變量大多於系統相關，getProperty方法返回的變量大多與java程序有關。

系統屬性和環境變量都是名稱與值之間的映射。兩種機制都能用來將用戶定義的信息傳遞給 Java進程。環境變量產生更多的全局效應，因為它們不僅對Java子進程可見，而且對於定義它們的進程的所有子進程都是可見的。在不同的操作系統上，它們的語義有細微的差別，比如，不區分大小寫。因此環境變量更可能有意料不到的副作用。程序中儘可能使用系統屬性。環境變量應該在需要全局效應的時候使用，或者在外部系統接口要求使用環境變量時使用（比如 PATH）。

1、環境變量getenv() ：用於獲取當前系統環境的字符串映射視圖；測試代碼及運行結果如下：

publicclass Test {

publicstaticvoid main(String[] args) {

MapString, String map = System.getenv();

for(IteratorString itr = map.keySet().iterator();itr.hasNext();){

String key = itr.next();

System.out.println(key + “=” + map.get(key));

}

}

}

USERPROFILE ：用戶目錄

USERDNSDOMAIN ：用戶域

PATHEXT ：可執行後綴

JAVA_HOME ：Java安裝目錄

TEMP ：用戶臨時文件目錄

SystemDrive ：系統盤符

ProgramFiles ：默認程序目錄

USERDOMAIN ：帳戶的域的名稱

ALLUSERSPROFILE ：用戶公共目錄

SESSIONNAME ：Session名稱

TMP ：臨時目錄

Path ：path環境變量

CLASSPATH ：classpath環境變量

PROCESSOR_ARCHITECTURE ：處理器體系結構

OS ：操作系統類型

PROCESSOR_LEVEL ：處理級別

COMPUTERNAME ：計算機名

Windir ：系統安裝目錄

SystemRoot ：系統啟動目錄

USERNAME ：用戶名

ComSpec ：命令行解釋器可執行程序的準確路徑

APPDATA ：應用程序數據目錄

2、系統屬性getProperty() ：當前的系統屬性。測試代碼及運行結果如下：

java.version Java ：運行時環境版本

java.vendor Java ：運行時環境供應商

java.vendor.url ：Java供應商的 URL

java.home ：Java安裝目錄

java.vm.specification.version： Java虛擬機規範版本

java.vm.specification.vendor ：Java虛擬機規範供應商

java.vm.specification.name ：Java虛擬機規範名稱

java.vm.version ：Java虛擬機實現版本

java.vm.vendor ：Java虛擬機實現供應商

java.vm.name ：Java虛擬機實現名稱

java.specification.version：Java運行時環境規範版本

java.specification.vendor：Java運行時環境規範供應商

java.specification.name ：Java運行時環境規範名稱

java.class.version ：Java類格式版本號

java.class.path ：Java類路徑

java.library.path ：加載庫時搜索的路徑列表

java.io.tmpdir ：默認的臨時文件路徑

java.compiler ：要使用的 JIT編譯器的名稱

java.ext.dirs ：一個或多個擴展目錄的路徑

os.name ：操作系統的名稱

os.arch ：操作系統的架構

os.version ：操作系統的版本

file.separator ：文件分隔符

path.separator ：路徑分隔符

line.separator ：行分隔符

user.name ：用戶的賬戶名稱

user.home ：用戶的主目錄

user.dir：用戶的當前工作目錄

java程序操作sql報錯 錯誤為： 並非所有變量都已綁定

您好，建議把sql語句在數據庫中執行下，看能否正確執行。

我想大概是表裡面所有的字段，你沒有給全部賦值。

因為你insert into t_login 後面沒有具體字段，那麼就是全表的所有字段。

values後面給了三個字段。

jdbc查詢數據庫報：java.sql.SQLException: ORA-01006: 綁定變量不存在

胡亂猜測一下。

int i = 1;

if(um.getUuid() != null um.getUuid().trim().length() 0){

pstmt.setString(i, um.getUuid());

i++;

}

java中所有這種類似數組的東西，都應該是從0開始，而不是從1開始。

所以 int i = 0;

Java程序員在寫SQL時常犯的錯誤！

Java程序員編程時需要混合面向對象思維和一般命令式編程的方法，能否完美的將兩者結合起來完全得依靠編程人員的水準：

技能（任何人都能容易學會命令式編程）模式（有些人用“模式-模式”,舉個例子,模式可以應用到任何地方，而且都可以歸為某一類模式）心境（首先，要寫個好的面向對象程序是比命令式程序難的多，你得花費一些功夫）

但當Java程序員寫SQL語句時，一切都不一樣了。SQL是說明性語言而非面向對象或是命令式編程語言。在SQL中要寫個查詢語句是很簡單的。但在Java里類似的語句卻不容易，因為程序員不僅要反覆考慮編程範式，而且也要考慮算法的問題。

下面是Java程序員在寫SQL時常犯的10個錯誤（沒有特定的順序）。

1、忘掉NULL

Java程序員寫SQL時對NULL的誤解可能是最大的錯誤。也許是因為（並非唯一理由）NULL也稱作UNKNOWN。如果被稱作 UNKNOWN，這還好理解些。另一個原因是，當你從數據庫拿東西或是綁定變量時，JDBC將SQL NULL 和Java中的null對應了起來。這樣導致了NULL = NULL（SQL）和null=null（Java）的誤解。

對於NULL最大的誤解是當NULL被用作行值表達式完整性約束條件時。另一個誤解出現在對於NULL 在 NOT IN anti-joins的應用中。

解決方法：

好好的訓練你自己。當你寫SQL時要不停得想到NULL的用法：這個NULL完整性約束條件是正確的？NULL是否影響到結果？

2、在Java內存中處理數據

很少有Java開發者能將SQL理解的很好。偶爾使用的JOIN,還有古怪的UNION，好吧，但是對於窗口函數呢？還有對集合進行分組呢？許多 的Java開發者將SQL數據加載到內存中，將這些數據轉換成某些相近的集合類型，然後再那些集合上面使用邊界循環控制結構（至少在Java8的集合升級 以前）執行令人生厭的數學運算。

但是一些SQL數據庫支持先進的（而且是SQL標準支持的）OLAP特性,這一特性表現更好而且寫起來也更加方便。一個（並不怎麼標準的）例子就 是Oracle超棒的MODEL分句。只讓數據庫來做處理然後只把結果帶到Java內存中吧。因為畢竟所有非常聰明的傢伙已經對這些昂貴的產品進行了優 化。因此實際上,通過將OLAP移到數據庫，你將獲得一下兩項好處：

便利性。這比在Java中編寫正確的SQL可能更加的容易。性能表現。數據庫應該比你的算法處理起來更加快.而且更加重要的是,你不必再去傳遞數百萬條記錄了。

解決方法：

每次你使用Java實現一個以數據為中心的算法時，問問自己：有沒有一種方法可以讓數據庫代替為我做這種麻煩事。

3、使用UNION代替UNION ALL

和UNION相比UNION ALL還需要額外的關鍵字。如果SQL標準已經規定了支持，那麼可能會更好點。

UNION（允許重複）UNION DISTINCT （去除了重複）

移除重複行不僅很少需要（有時甚至是錯的），而且對於帶很多行的大數據集合會相當慢，因為兩個子select需要排序，而且每個元組也需要和它的子序列元組比較。

注意即使SQL標準規定了INTERSECT ALL和EXCEPT ALL，很少數據庫會實現這些沒用的集合操作符。

解決方法：

每次寫UNION語句時，考慮實際上是否需要UNION ALL語句。

4、通過JDBC分頁技術給大量的結果進行分頁操作

大部分的數據庫都會支持一些分頁命令實現分頁效果，譬如LIMIT..OFFSET,TOP..START AT,OFFSET..FETCH語句等。即使沒有支持這些語句的數據庫，仍有可能對ROWNUM（Oracle）或者是ROW NUMBER()、OVER()過濾（DB2、SQL Server2008等），這些比在內存中實現分頁更快速。在處理大量數據中，效果尤其明顯。

解決方法：

僅僅使用這些語句，那麼一個工具（例如JOOQ）就可以模擬這些語句的操作。

5、在Java內存中加入數據

從SQL的初期開始，當在SQL中使用JOIN語句時，一些開發者仍舊有不安的感覺。這是源自對加入JOIN後會變慢的固有恐懼。假如基於成本的 優化選擇去實現嵌套循環，在創建一張連接表源前，可能加載所有的表在數據庫內存中，這可能是真的。但是這事發生的概率太低了。通過合適的預測，約束和索 引，合併連接和哈希連接的操作都是相當的快。這完全是是關於正確元數據（在這裡我不能夠引用Tom Kyte的太多）。而且，可能仍然有不少的Java開發人員加載兩張表通過分開查詢到一個映射中，並且在某種程度上把他們加到了內存當中。

解決方法：

假如你在各個步驟中有從各種表的查詢操作，好好想想是否可以表達你的查詢操作在單條語句中。

6、在一個臨時的笛卡爾積集合中使用 DISTINCT 或 UNION 消除重複項

通過複雜的連接，人們可能會對SQL語句中扮演關鍵角色的所有關係失去概念。特別的，如果這涉及到多列外鍵關係的話，很有可能會忘記在JOIN .. ON子句中增加相關的判斷。這會導致重複的記錄，但或許只是在特殊的情況下。有些開發者因此可能選擇DISTINCT來消除這些重複記錄。從三個方面來說 這是錯誤的：

它（也許）解決了表面癥狀但並沒有解決問題。它也有可能無法解決極端情況下的癥狀。對具有很多列的龐大的結果集合來說它很慢。DISTINCT要執行ORDER BY操作來消除重複。對龐大的笛卡爾積集合來說它很慢，還是需要加載很多的數據到內存中。

解決方法：

根據經驗，如果你獲得了不需要的重複記錄，還是檢查你的JOIN判斷吧。可能在某個地方有一個很難覺察的笛卡爾積集合。

7、不使用MERGE語句

這並不是一個過失，但是可能是缺少知識或者對於強悍的MERGE語句信心不足。一些數據庫理解其它形式的更新插入（UPSERT）語句， 如 MYSQL的重複主鍵更新語句，但是MERGE在數據庫中確是很強大，很重要，以至於大肆擴展SQL標準，例如SQL SERVER。

解決方法：

如果你使用像聯合INSERT和UPDATE或者聯合SELECT .. FOR UPDATE然後在INSERT或UPDATE等更新插入時，請三思。你完全可以使用一個更簡單的MERGE語句來遠離冒險競爭條件。

8、使用聚合函數代替窗口函數（window functions）

在介紹窗口函數之前，在SQL中聚合數據意味着使用GROUP BY語句與聚合函數相映射。在很多情形下都工作得很好，如聚合數據需要濃縮常規數據，那麼就在join子查詢中使用group查詢。

但是在SQL2003中定義了窗口函數，這個在很多主流數據庫都實現了它。窗口函數能夠在結果集上聚合數據，但是卻沒有分組。事實上，每個窗口函數都有自己的、獨立的PARTITION BY語句，這個工具對於顯示報告太好了。

使用窗口函數：

使SQL更易讀（但在子查詢中沒有GROUP BY語句專業）提升性能，像關係數據庫管理系統能夠更容易優化窗口函數

解決方法：

當你在子查詢中使用GROUP BY語句時，請再三考慮是否可以使用窗口函數完成。

9、使用內存間接排序

SQL的ORDER BY語句支持很多類型的表達式，包括CASE語句，對於間接排序十分有用。你可能重來不會在Java內存中排序數據，因為你會想：

SQL排序很慢SQL排序辦不到

解決方法：

如果你在內存中排序任何SQL數據，請再三考慮，是否不能在數據庫中排序。這對於數據庫分頁數據十分有用。

10、一條一條地插入大量記錄

JDBC“懂”批處理（batch），你應該不會忘了它。不要使用INSERT語句來一條一條的出入成千上萬的記錄，（因為）每次都會創建一個新 的PreparedStatement對象。如果你的所有記錄都插入到同一個表時，那麼就創建一個帶有一條SQL語句以及附帶很多值集合的插入批處理語 句。你可能需要在達到一定量的插入記錄後才提交來保證UNDO日誌瘦小，這依賴於你的數據庫和數據庫設置。

解決方法：

總是使用批處理插入大量數據。

來自：OSChina

譯者：oschina.net/translate/10-common-mistakes-java-developers-make-when-writing-sql