컴퓨터 이야기 231

SQL 쿼리를 JSP 에서 구현하는 이유

예전에 이렇게 코딩된 JSP 를 본 적이 있다. DB 작업을 위한 Context, Connection, Statement, ResultSet 등이 JavaBeans 에 담긴 것이 아니라 JSP 에 존재하는 것이다. 물론 ResultSet 이야 JSP 에서 사용하려면 기술될 수도 있다. 그런데, ResultSet 의 맹점(?)이 몇가지 존재하기 때문에, 이것도 ArrayList 에 담기 쉽상이다. 그리고 이러한 코딩 방식을 폄하한 가장 큰 이유는, PreparedStatement 를 이용하지 않고 Statement 를 이용하였기 때문이다. 게다가 유사한 기능을 구현한 각각의 JSP 들에 처음부터 끝까지 DB 작업용 코드가 들어가 있지 않은가..! 비슷한 기능을 수정하려고 관련된 JSP 모두를 고쳐야 하니,..

WareValley 사의 Orange 에서 그리드 헤더 복사 옵션

오렌지의 그리드에서 복사를 하면 간혹 해당 그리드의 헤더 부분이 복사될 때가 있다. 그래서, 해당 그리드의 셀을 더블클릭 하고 블럭을 잡아 복사를 했다. 오렌지의 옵션에 보면 파일 저장시 헤더를 포함하는 항목이 있는데, 이 항목은 디스크에 저장할 때의 옵션이고 클립보드에 복사해 넣는 것과는 무관하다. 이미 알고 계신분들이야 '당연한 얘기를 왜 하느냐' 하실지 모르지만.. 나와 같은 사람도 있을테니 설명을 하자.. (참고로, 필자는 오렌지를 ReInstall 하여 해결했었다.. ㅠㅠ) 이곳에서 설명하는 버전은 DBA Edition 4.0.1 이다. 다른 버전에서는 어떻게 구현되어 있는지 모르겠다.. ^^> 위에서 설명을 했지만, 디스크에 저장시 헤더를 포함시키는 방법은 아래와 같다. 메뉴에서 'Option..

connect by ~ start with ~ order siblings by ~ 문에 대한 Oracle 9i Plan (실행계획) 2

이번에 설명하는 것은 ACL 을 사용자별로 다루지 않고 그룹단위로 다루는 경우를 설명한다. 이보다 더 나은 방법도 얼마든지 많을테지만.. 먼저 실행계획부터.. (눈이 마구 돌아가져.. ㅋㅋ) 아래 그림을 보면 딱 눈에 보이시죠..? Filter 와 Hash Join, Count 등에 Nested Loops (Cost=471 Card=23 Bytes=3K) 가 동일하게 사용되었습니다. 그 안쪽에 있는 Nested Loops (Cost=2 Card=23 Bytes=1K) 는 테이블을 악세스 하지 않고 Index 에서만 돕니다. 이제 쿼리를 함 보겠습니다. 위에서 설명했던 첫번째 Netsted Loop 에 해당하는 것이 (select seq_category ~ group by seq_category) 입니다...

이클립스 Revert to Base, 잘못 수정한 소스를 최종적으로 저장했던 내용으로 원복

무언가 수정 작업을 하고 있는데, 하도 이것저것 수정하다 보니 갑자기(?) 프로그램이 어떻게 돌아가고 있는 것인지 감이 잡히지 않을 때가 있다. 이를테면, A.java 를 한창 수정하고 있는데.. B.java 에서 코드를 일부 복사해 와서 붙여넣기 하고, 이것저것 한참 수정하다가.. 갑자기 어디에서 잘못했는지 기억이 나지 않는다. 다급하게 Ctrl-z 를 열심히 누르고 있는데.. 중간에 더이상 Undo 가 안 된다.. 이런 경우.. 참 고민이 많다. 왜 이클립스는 울트라에디트나 에디트플러스 처럼 거의 무제한 Undo 가 안 될까..? 어떤 분은 Undo 의 버퍼 사이즈를 크게 늘리는 분도 있는데, 이것도 무제한은 아니니까.. 이럴때 아직 저장을 하지 않았다면 마지막으로 저장했던 소스로 원복하는 기능이 있..

자바스크립트나 스타일시트를 JSP 에서 구현하는 이유..?

이곳에서 이야기 하는 내용은 명확한 근거 자료를 기준으로 설명하지는 않았다. 순전히 경험적인 요소를 기준으로 알맞게 재구성해 놓았음을 미리 밝힌다. 아마도 다른 곳에서 이 곳에 기술된 내용을 인용한다면 무언가 심각한 오해를 유발할 수도 있음을 경고한다. 그렇다고 아주 엉뚱한 이야기를 하는 것은 아니다. 자바스크립트는 .js 확장자로 작성하고 웹서버 (Web Server) 경로에 위치시키는 것이 관례(?)다. 마찬가지로 스타일시트는 .css 확장자로 작성하고 웹서버 경로에 위치시킨다. 혹, 왜 이렇게 사용하는지 모르는 분들이 계신 것같긴 하지만.. 이렇게 하면 좋은 점이.. 사용자의 PC 에 .js 와 .css 가 한번 다운로드 받아지면, 그 내용이 바뀌지 않는다는 가정하에.. 다음 웹페이지에서 동일한 ...

CSS 를 이용한 수직 가운데 정렬, table 태그냐 div 태그냐..?

아래 코드를 사용하면 3개의 input 태그는 수직으로 가운데 정렬이 되는데, 나머지 img 태그는 위쪽으로 붙어 버린다. img 태그에 padding 이나 margin 스타일을 먹여도 요지부동. - 역시 구관이 명관이라고, table 태그로 전환하면 해결이 되는데.. 만약 td 태그 안에 여러 내용이 혼합되어 사용된다면 td 태그에 속성을 더 설정해 주어야 한다. - 아래와 같이 vAlign 속성을 middle 로 주거나, align 속성에 middle 을 주면 해결. vAlign 에 middle 을 주거나 align 에 center 를 주는 것은 봤지만, align 에 middle 을 준다꼬..? 한번 해 보시라. 그런데, 코드가 복잡해 졌다.. 이거는 조금 곤란해 졌네.. 크윽. - 다시 div 형..

connect by ~ start with ~ order siblings by ~ 문에 대한 Oracle 9i Plan (실행계획)

connect by ~ start with 문에서 정렬하는 방법. order siblings by ~ 활용. 다음은 connect 문에 넣기 전에 미리 order by 를 해 놓는 경우이다. Index 힌트를 사용하여 다른 인덱스를 태우지 않도록 제한을 걸었다 (그래도 Optimizer 마음대로 하겠지만..). 그런데, 이렇게 하면.. 실행계획이 복잡하게 된다. srart with 문이나 connect by 에도 order by 의 sort 계획이 잡히게 된다. select * from (select /*+ index(a table_category_idx04) */ a.seq_category, a.bef_category, a.name, a.depth, a.ordr, a.link_url from table..

Ajax 사용할 때 알아 두면 편리(?)한 4가지 이야기

별도의 프레임 웍을 사용하지 않고, 기본적인 Ajax 를 다룰때 유념해야 할 몇가지 사항이 있다. 첫째, Ajax 로 불려지는 웹페이지와 Ajax 로 불러오는 웹페이지의 프로토콜이 같아야 한다. 둘째, 스타일시트와 자바스크립트의 정의는 Ajax 에서 하지 않는다. 셋째, Get 방식과 Post 방식을 사용할때 둘 간에는 약간의 차이가 존재한다. 넷째, Ajax 는 파라미터를 주고 받을때 UTF-8 을 사용한다. 자, 이제 이야기를 시작해 보자. 우선 첫번째 프로토콜. 여기서 말하는 프로토콜은 웹에서 사용하는 HTTP 와 HTTPS 를 말하는 것이다. A.jsp 가 Ajax 기술(?)을 사용하여 B.jsp 를 불러올때, A.jsp 가 HTTP 이면 B.jsp 도 HTTP 로 불러오고.. A.jsp 가 HT..

오라클 DB 성능 향상 엑셈 MaxGauge

Maxgauge 개발회사 엑셈 홈페이지 -> http://www.ex-em.com/ -> 엑셈에서 다양한 세미나 등을 하는데 성능 관련 및 OWI 등은 들으면 도움이 되실듯 함..^^ 제품 설명 자료 -> http://www.ex-em.com/web/support/support_databank1.php?dtype=1 -> 목록중에 [MaxGauge 교육자료 Ver3.1] 를 Down 받아서 참고 제품 매뉴얼 -> http://www.ex-em.com/web/support/support_databank1.php?dtype=1 -> 목록중에 [MaxGauge 3.1(Oracle) 매뉴얼 vol.1 / 2] 를 참고 오라클 백과사전 -> http://wiki.ex-em.com/index.php/ -> 엑셈에서..

오라클 DB 의 Lock 을 염두에 둔, 레코드 업데이트

하나 이상의 프로세스를 통하여 동일 레코드의 특정 칼럼 값(들)을 수정하는 경우, 어떤 것이 적용될까..? 순식간에 발생하더라도 마지막에 update 가 수행된 하나만 반영이 될터인데.. 그러면, 반영되기는 했지만 최종적으로는 적용되지 않은 쪽이 억울하지 않을까..? 해당 레코드가 여러번 수정되어도 마지막에 수정된 내용만 남게 되기도 하고.. 이를 방지하기 위해서, 검린 님이 2가지 방법을 기술하였는데.. 하나는, 칼럼(columnA)을 하나 추가해서 마지막에 수정한 일시(timestamp)를 가지게 하고, 동일 레코드를 읽을때 추가된 칼럼 columnA 값을 읽어서 가지고 있다가, update 문의 조건절에 최종 수정일시 columnA 를 조건으로 추가하면 된다는 것. A 와 B 가 언제든 해당 레코드..