java.sql.Statement
public interface Statement
extends Wrapper

정적 SQL 문을 실행해, 작성된 결과를 돌려주기 위해서(때문에) 사용되는 객체입니다.  

디폴트에서는,Statement 객체 마다 1 개의 ResultSet 객체만이 동시에 오픈할 수 있습니다. 따라서, 1 개의 ResultSet 객체의 read가, 다른 read에 의해 끼어들어지면(자), 각각은 다른 Statement 객체에 의해 생성된 것이 됩니다. Statement 인터페이스의 모든 execution 메소드는, 문장의 현재의 ResultSet 객체로 오픈되고 있는 것이 존재하면, 그것을 암묵에 클로즈 합니다.

관련 항목:
Connection.createStatement() , ResultSet

java.sql.PreparedStatement
public interface PreparedStatement
extends Statement

프리컴파일 된 SQL 문을 나타내는 객체입니다.  

SQL 문은, 프리컴파일 되어PreparedStatement 객체에 포함됩니다. 거기서, 이 객체는, 이 문장을 여러 차례 효율적으로 실행하는 목적으로 사용할 수 있습니다.

주: IN 파라미터치를 설정하는 설정 기능 메소드 (setShort,setString 등)는, 입력 파라미터의 정의된 SQL 형과 호환이 있는 형태를 지정하지 않으면 안됩니다. 예를 들어, IN 파라미터에 INTEGER 라고 하는 SQL 형이 있는 경우,setInt 메소드를 사용하지 않으면 안됩니다.

임의의 파라미터형 변환이 필요한 경우는,setObject 메소드는, 목적의 SQL 형으로 사용하지 않으면 안됩니다.  

파라미터 설정의 예를 다음에 나타냅니다. con 는 액티브한 접속을 나타냅니다.

PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
SET SALARY = ? WHERE ID = ? ");
pstmt.setBigDecimal(1, 153833.00)
pstmt.setInt(2, 110592)
 

관련 항목:
Connection.prepareStatement(java.lang.String) , ResultSet

PreparedStatement 에 대한 설명 : http://pcguy7.springnote.com/pages/1052420
Summary 그래서 우리는 prepared statements를 파라메터와 함께 사용해야한다. 이것은 미리 만들어진 접근 계획을 재 사용하므로서 데이터 베이스에 대한 로드를 줄여 준다. 이 cache는 데이터 베이스가 확장된 것이어서 여러분의 모든 애플리케이션이 유사한 파라메터화된 sql을 사용하면 하나의 애플리케이션이 다른 애플리케이션에 의해 사용된 prepared statements를 이용하므로 캐시 스키마의 효율성을 증대 시킬 수 있다. 이것은 application server 사용의 이점이다. 왜냐하면 데이터 베이스에 접근하는 로직은 데이터 접근 계층에 집중화 되어야하기 때문이다. 두번째로 prepared statements의 올바른 사용은 또한 여러분이 애플리 케이션 내부의 prepared statements cache를 잘 이용할 수 있게 한다. 이것은 애플리케이션이 이전에 사용했던 prepared statements 호출을 재사용해서 JDBC driver에 대한 호출의 수를 감소시켜 성능의 향상을 시킨다. 이것은 현명한 fat clients 사용을 효율적으로 그리고 경쟁력있게 만들고 독점적인 connection을 유지할 수 없는 불이익을 제거한다. 만약 파라메타화된 prepared statements를 사용한다면 여러분은 데이터 베이스와 코드를 가지고 있는 application server의 효율을 높일 수 있다. 이들 개선된 점은 여러분의 애플리케이션의 성능을 향상 시킬수 있게 할것이다.


내 나름의 중요한 결론을 말해보자면, 'PreparedStatement를 잘 활용하면 CPU 사용량을 줄이고 DB에 접근하는 소프트웨어의 속도를 향상시키는 효과가 있다'는 것이다.

ㅡㅅ-)> 내가 쓰기 불편하다고 Statement 형식으로 많이 썼었는데, 이제 PreparedStatement를 사용해야겠다. 나란 녀석도 참 고집이 쎄다. 그렇게 쓰는 장점이 있는데도, 내가 쓰기 편하다고 그 방식을 외면하고 있으니 말이다. 

String 은 Charecter Line을 나타낸다. Character Line 객체는 변형되지 않기 때문에 공통으로 사용할 수 있다.
그 값을 바꾸기 위해서는 필요에 따라 대입을 시켜줘야 한다.

StringBuffer는 Thread를 사용할 수 있는 변형이 가능한 캐릭터라인이다. 
예를 들어,
 StringBuffer z = "start";
라고 한 경우, 
z.append("le")라고 하면 z의 내용은 "startle"가 되며, z.insert(4,"le")라고 하면 z의 내용은 starlet가 된다.

두 클래스 다 직렬화(Serializable)를 지원하는구나. ㅡㅅ-);;

참고 : http://hongsgo.egloos.com/2033998 요 글을 보면, String < StringBuffer < StringBuilder 속도 차이가 있다. 흠... String은 적게 쓰는게 좋군요. ㅡㅅ-);;

참고 : http://cacky.tistory.com/36

  • String : 변경되지 않는 Character 문자열 객체
    문자열이 변경되지 않을 경우에는 String 사용
  • StringBuffer : 값이 변경 가능 // 동기화 가능 : 다중 스레드 일 경우에 사용
    문자열이 변경되고 다중 스레드에서 사용될 경우 사용
  • StringBuilder : 값이 변경 가능 // 동기화 되지 않음 : 단일 스레드일 경우에 사용
    문자열이 변경되고, 단일 스레드에서 사용될 경우 사용
마침 넷빈즈를 실행시켜보니 스타트 페이지에 다음과 같은 내용들이 나오기에 가만히 보다가 관련한 블로그에서 Java IDE로 무엇을 사용하는지에 대한 투표를 하는 블로그가 연결되어 있었다. 그래서 사이트에 가서 투표를 해봤다. 

결과는 보는 것처럼 이클립스 쪽이 우세한 상황이다. 그 뒤를 넷빈즈가 바짝 뒤쫓고 있다.
JavaFX에 대한 플러그인과 썬사의 적극적인 지원으로 넷빈즈도 자바 IDE로서 조금씩 유용하게 쓰이고 있는 것 같다.
하지만... 아직은 이클립스쪽이 조금 더 낫지. ^^ 힘내라!!



JDK 7 버전이 릴리즈 된지 얼마 되지 않았다.

Host: Ed Ort, Senior Staff Information Engineer, Sun Microsystems
Guest: Danny Coward, Chief Architect for Client Software at Sun Microsystems

두 사람이 나누는 대담을 통해 JDK 7 에 깊이 빠져들어가보자.


JDK 7 : Top 5 New Features

#1 : Modularity
#2 : Multi-Language
#3 : New Garbage Collectors
#4 : Nio.2 File System APIs
#5 : Swing API Additions

#1 : Modularity
// Declaring that a class belongs to a module:
module M;
package P;

public class Foo {...}

//Defining a module in a module-info.java file

module M @1.0 {
requires N @2.1;
requires L @0.5;
}
Java SE 7 : Project Jigsaw
  • Low Level Modularity System in JDK 7
  • Breaking Up the JDK 7 Code
  • Packaging Format
  • Uses Java Language Modularity(JSR 294) // ㅡㅅ-);; JSR 은 뭐지?
http://openjdk.java.net/projects/jigsaw
http://jcp.org/en/jsr/detail?id=294

아래에 나오는 내용은 "Coin Project"란다.


String animal ="...";
   
    if ( animal.equals("dog")) {
        takeForWalk(animal);
    } else if ( animal.equals("cat")) {
        leaveMilkFor(animal);
    } else if ( animal.equals("mouse")) {
        cleanCageFor(animal);
    } else {
        leaveOutside(animal);
    }
※  JDK 7 에서는 switch 에서 case에 char 타입 이외에 String 타입도 사용이 가능하게 됩니다. 조건문이 쉬워지는군요.
    String animal = "...";
   
    switch(animal) {
    case "dog" : takeForWalk(animal);
    case "cat" : leaveMilkFor(animal);
    case "dog" : cleanCageFor(animal);
    default : leaveOutside(animal);
    }

※ Exception 처리
try {
        doWork(file);
    } catch ( IOException ioe ) {
        logger.log(ioe);
        throws ioe;
    } catch ( SQLException sqle ) {
        logger.log(sqle);
        throws sqle;
    }
  JDK 7 에서는 이렇게 가능하다. Ed Ort 씨 처럼 Ah~~ha~~!!
try {
        doWork(file);
    } catch ( final IOException | SQLException ex ) {
        logger.log(ex);
        throws ex;
    }

※ 다음은 Genericㄴ 사용법 : 아직 본인은 generics 사용법에 대해서 익숙하지 못하다. ㅡㅅ-);;;
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
JDK 7 에서는 이렇게 된다고 한다. ㅡㅅ-)b
Map<String, List<String>> anagrams = new HashMap<>();

※ 다음은 Operator
Object anObject;
    ...
    if (anObject == null ) {
        s = "nothing";
    } else {
        s = anObject.toString();
    }
   
    int i;
    ...
    if ( anInteger == null ) {
        i = -1;
    } else {
        i = anIntegerr;
    }
JDK 7 에서는 이렇게 바뀐다고 한다. " ?:  " 요놈인 건데... ㅡㅅ-)> 요건 뭐가 좋은거지? ?: == null 인건가?
   String s = anObject?.toString() ?: "nothing";
    int i = anInteger ?:-1;


#2 : Multi-Language  : supporting non-Java languages at the VM level
JVM에서의 실행속도를 높인다는 건가? Bytecode를 역동적으로!? 메소드 핸들러를 가볍게!? 최적화를 변동적으로?
Broadening the JVM to Accelerate Runtimes
  • Bytecode for Dynamic Invocation
  • Lightweight Method Handles
  • A Variety Of Other Possible Optimizations
JRuby is the Pioneer
The DaVinci Project
http://openjdk.java.net/projects/mlvm

#3 : New Garbage Collectors - Garbage First,
Predictably Low Pauses + Few Full Garbage Collectors + Good Throughput
Greate for a Wide Variety of Application

#4 : Nio.2 File System APIs
DirectorySearchOperations 라는 클래스가 추가된 듯 하다. 자바로 새로운 파일 시스템을 사용해볼 기회가 있었어야 말이지..ㅡㅅ-);; 흠...
  • New Filesystem API File Notifications Directory Operations
  • Asynchronous I/O

#5 : Swing API Additions
  Java의 Swing API에 대한 불만은 여전히 있었고, ㅡㅅ-);; 추가되었다는 내용을 봐도 불만은 여전히 유지가 될 것 같다. 사용자가 필요에 따라서 자신이 디자인한 부분에 대해서 적용할 수 있도록 해주면 좋지 않을까? ㅡㅅ-)~ 현재 나는 조용히 쓰라는 대로 써야지. ㅎㅎ.
JSR 296 : Swing Application Framework
http://jcp.org/en/jsr/detail?id=296

JDK 7 과 관련된 홈페이지(MileStone)
JDK 7 Milestones Homepage
http://openjdk.java.net/projects/jdk7/milestones/
openJDK Project Homepage
http://openjdk.java.net/project/jdk7/
JDK 7 Project Homepage
https://jdk7.dev.java.net/
The Planetarium Blog
http://blogs.sun.com/theplanetarium/

[개발철학] Simple more Simple

단순명료(單純明瞭)함.

  나의 개발철학은 이 한마디로 정리할 수 있을 듯 하다. 다른 이들이 보아도 나의 개발철학은 단순명료함을 유지하여 적은 시간을 투자하여 빠른 이해와 높은 활용성을 얻도록 하는 것을 목적으로 하고 있다. 나와 동문수학한 다른 이들을 도와주기 위해 그들이 작성한 코드를 가만히 들여보고 있자면, 한숨이 절로 나오는 경우가 있다. 자신이 지정한 변수가 어떤 타입인지 모르고 전혀 엉뚱한 타입으로 받아서 생기는 오류(이클립스와 같은 IDE 툴을 사용하는데도 종종 볼 수 있었다)에서 시작해서 자신이 생각해낸 알고리즘이 아니라, 단순히 인터넷 검색을 통해 나와있는 코드를 그대로 복사해서 붙이면서 발생한 이해불능의 기능으로 인해서 읽기 어려움에 빠진다. 그것을 보면서 나는 저렇게 해서는 안되겠다는 생각을 다짐하고 또 다짐했다. 그와 동시에 이런 나의 생각을 내 개발습관 속에 서서히 녹아들도록 만들었다. 철저하게 코딩스타일을 유지하며 낯설은 부분에서는 이해하기 쉽도록 주석을 첨가하고, 가급적이면 한줄에 하나의 명령어만을 구현하도록 노력했다. 코드는 자기가 봤을 때도 이해하기 쉽고 다른 사람이 봤을 때도 이해하기 쉽게 만들어져야 한다.

   C언어를 배우는 초기에는 컴퓨터의 제약조건들 때문에 한줄에도 많은 명령어를 구현하려고 노력했었다. 하지만, 지금에 와서 PC의 성농은 비약적으로 증가되었으며, 객체지향언어가 발달하고 널리 사용되면서 굳이 적은 코드파일 크기를 고집할 필요성이 약해지고 있다. 이런 상황에서 나는 코드의 가독성과 이해력을 높이기 위해서라면, 한 줄로 끝날 계산도 가급적이면 나누고 나누어서 표현을 하려고 노력한다. 그것이 나의 Simple more Simple 개발철학이다. 이런 나의 개발철학은 나의 개발물들을 후에 다른 사람들이 수정할 일이 생겼을 때 수정하여 사용하기 쉽도록 하여 내 코드의 재활용성을 높여줄 것이다.

  간혹 프리랜서로 일한 사람들의 코드를 보면 쉽게 이해할 수 없는 부분들이 많은 경우가 있다. 이에 대한 문서화도 제대로 되지 않아서 급하게 수정해야할 경우 난해한 경우가 생긴다. 프리랜서로서 그렇게 해야 다시 자신들을 불러줄 거라고 생각하는지 모르겠지만, 개인적으로 그런 습관을 가지고 있는 프리랜서라면 나는 다시는 안 쓴다.  깔끔하고 이해하기 쉬운 코딩스타일을 가지고 있으면서 문서화를 잘하는 프로그래머와 계속 함께 일하고 싶어할 거니까. 나 역시 그런 프로그래머가 되려고 노력할 것이다.

구인정보를 읽다가 개발철학에 대해서 묻는 질문에 대해서 잠시 곰곰히 생각을 해보았다. 나는 단순히 일자리가 없어서 개발자가 되려는 것이 아니라, 이 분야에서 계속 일하고 싶기 때문에 5개월동안 교육을 받은 것이고, 오랫동안 개발자로서 인정받고 성장하기 위해서는 내 개발철학을 가지고 소신껏 살아갈 필요가 있는 것이다. 그래서 개발철학을 생각해본다.

이 글은 스프링노트에서 작성되었습니다.

+ Recent posts