반응형 TechNical/Oracle47 LEFT OUTER JOIN 성능. 꼭 필요할 떄만 쓰자~ LEFT OUTER JOIN을 동일한 테이블을 조건만 다르게 해서 여러게 붙여 놓은 쿼리가 있었다. 속도가 겁니 느려서 분산된 LEFT OUTER JOIN 을 하나로 빼고 해당 테이블에서 다른 조건들은 SELECT 문에서 DECODE나 CASE문으로 빼니까 성능이 좋아진 경우가 있었다. 플렌을 떴을 경우 별 차이는 없었지만 실제 실행 속도는 차이가 많았다. 이에 따라 LEFT OUTER JOIN 의 성능이 어떤가 하고 찾아보니 아래와 같은 TIP을 발견 했다. If you have a query that uses a LEFT OUTER JOIN, check it carefully to be sure that is the type of join you really want to use. As you may.. 2010. 3. 17. WITH 문에서 테이블을 두개 맹글어 보자. 원래 WITH문 이게 메인이 아닌데.. GROUP BY에 대한 고찰이었음.. =ㅅ= 마땅한 제목이 없어서. ㅋㅋㅋㅋㅋ 1. 테스트 테이블 생성 WITH tb1 AS ( select 'A' as k1 , 1 as qty from dual union all select 'B', 2 from dual union all select 'B', 3 from dual union all select 'C', 1 from dual ), tb2 AS ( select 'A' as b1 , '나무' as b2 from dual union all select 'B', '문어바' from dual union all select 'B', '꼬라바' from dual union all select 'C', '거북이' from dua.. 2009. 3. 13. 거지같은 CLOB 이랑 안면 트기... VARCHAR2 타입은 최대 길이가 4000byte 로 정해져 있다. 데이터가 4000바이트가 넘어가면 에러를 뱉어 낸다. 그런데 데이터라는 것이 4000 바이트로 성이 찰 리가 없다. 그래서 생겨난것이 CLOB 타입 인데... 4000 바이트를 넘어가니까 어쩔 수 없이 CLOB을 쓰긴 써야 되는데 이놈이 여간 거지 같은게 아니다. CLOB은 다른 애들이랑 어울리길 거부한다. 당연한 것이.. 타입이 틀리니까 .. NUMVER랑 CHAR랑 틀린거.. 뭐 똑같은 거다.. 근데 문제는 .. 이 놈은 타입케스팅이 거지 같다는 거다. 내가 잘 몰라서 그러겠지만.. 안 되는거 같다.. TO_LOB... 개나 줘라 그래 ㅡㅡ NVL은 되면서 DECODE, COALESCE는 까칠하게 싫다고 한다.. WHERE 절에 들.. 2008. 12. 8. 한 테이블의 모든 컬럼 업데이트 칠 때 오늘은 엄청 어려운 걸 해 볼 작정이다. 하하하하하 TEST 테이블에 NAME 컬럼 값이 있다고 치자. 이 놈이 원래는 char 형 타입이라서 10자리로 고정이 되어 있었다. 근데 이 놈을 마이그레이션 하면서 varchar2 타입으로 바꿔서 넘겼다. 아니 글쎄 그랬더니 이 놈이 우측에 공백이 다 붙어 있는 것이 아닌가!! 그래서 조회를 할 때 name = search_value 이런 식으로 찾으면 매치가 안 되는 것 이다. 그도 그럴 것이 공백도 문자로 인식하니까 안 맞을 수 밖에.... 얄팍하게 like 'search_value%' 이런식으로 찾을 수 있겠지만.. 이건 아무리 봐도 허접하다. 데이터는 무조건 맞춰야 한다. 자.. 그럼 update문을 어떻게 작성할 것 인가?!?!?!?!?!? 쉬울 것 .. 2008. 11. 24. 이전 1 2 3 4 5 6 ··· 12 다음 반응형