개끔찍하네요 헬파티

이유를 찾지 마세요 이거 좋은 예제 아닙니다

이런게 잔뜩 있을텐데 돌아가는게 신기하고 허구한날 터져도 그게 당연하다는 생각이 들 듯

-------아래는 추가내용

이렇게 조인 무슨무슨바이 무슨무슨바이 같은 어그리게이션 쿼리들을 무지성으로 걸어대면 좋지 않은 경우입니다

이걸 좋다고 하시는 분들이 계시네요 이게 품질이 좋은거라니..

많은 분들이 별로 안좋아하실 말 같은데 이래서 SI 추천 안드리는 겁니다 어떻게든 그 상황만 모면하는 쿼리입니다

SI식 한방쿼리라고 보는데 이런 길고 긴 심지어 이것보다 길고 복잡한 몇천줄 되는 쿼리 짜는걸 자랑스럽게 생각하는 분도 봤습니다 뭐 남의 프로덕트 돌아가게만 하면 되니 외주 받아오는 회사 입장에선 훌륭한 직원일수도 있겠습니다만, 개발자 개인으로는 과연 의문이네요

누가 이걸 유지보수 하고 싶겠어요 그냥 현재 상황만 모면하고 어때요 다됐죠? 잘 돌아가죠? 하고 어차피 자신이 유지보수 안할거기 때문에 이렇게 해놓는거죠

자신이 개발한 프로덕트를 계속 발전시켜나가고 유지보수할거라면 이렇게 해놓을까요? 절대 안하겠죠...ㅠ 

욕 먹을만한 각오하고 제 생각을 좀 더 추가해봤습니다

신입이시니 과감하게, 노력해서,

탈출하십쇼

SELECT 의 칼럼 선택이 많은 것이지 조인 자체는 어려운 부분이 없스빈다.

하지만 저렇게 조인을 하는 경우에 탐색 과정에 문제가 발생 할 수 있는데 서브 쿼리로 적절하게 나눠 주는 것이 필요하저.

특히 통계를 낼 때 자주 발생 하빈다.

여튼 뭐 이런 복잡한 과정 까지 이해를 하고 있으려면 경험도 축적이 되어 있어야 하겠지만 학문 자체도 깊어야 하빈다.

그렇다고 박사 급 까지는 아니고 어느 정도 경력을 갖추고 다양하게 해본 정도면 그 정도는 남들도 다 하빈다. 높은 티어 사람들이 적긴 하지만 ... 인원수 자체는 많을 것이빈다. 비중이 적을 뿐인것이저.

테이블 하나 조회해 보고 이해하고 하나 조인하고 돌려 보고 이해하고 그런 식으로 해서 완성해 나가 보세요.

left join 쓰는 이유는 한쪽에 키가 없으면 조인시 데이터 조회가 안 되기 때문에 이를 막기 위해 씁니다.

검색도 해 보시고 테스트 해 보시고, 이너 조인이랑 비교도 해 보시고 하면서 익혀 나가야겠죠.

그냥 컬럼이 많은 것 같네요 쿼리 자체는 어려운 것 같지 않습니다.

si sm에서 저정도 가독성 있는 쿼리

보기 쉽지 않으실 겁니다.

( 비교적 유지보수하기 괜찮다는 말씀 드리는겁니다. )

오늘 내일 처리해야하는 건 아니면

테이블 15개에 대한 ERD를 직접 그려보시는걸 추천드립니다.

시스템 구조 및 업무파악에 상당한 도움될 겁니다.

3,4번은 ( SQL 공부 꾸준히 하신다는 전제 하에 )

시간이 지나고 경험이 쌓이면 해결될 문제라고 봅니다.

쿼리 자체는 난이도 있는 쿼리가 아닙니다.

난이도 있는 함수나, 그룹핑도 없고요.

서브쿼리도 간단한 거네요.

그냥 컬럼이 많고, 조인이 좀 많을 뿐입니다.

조건절로 깔끔하게 잘 나눠져있고

가독성도 나름 규칙에 맞춰서 작업한 품질 좋고 훌륭한 쿼리입니다.

SQL 문 만 볼게 아니라 ERD 를 보고 테이블 구조를 파악하는게 먼저 입니다.

익숙하지 않으면, ERD 를 직접 그리면서 깊이 생각해 보고 이해하는 것도 크게 도움이 됩니다.

https://www.erdspace.com  무료 ERD  TOOL 인데요, 한번 사용해보세요 :)

암튼, ERD 를 보고 엔티티들과 그 관계를 이해하고 업무를 파악하는 건 개발자 필수 역량입니다.

더 나아가 비지니스를 분석해 ERD 설계 가능하면 베리 굿입니다.

좀 하다보면 크게 어려울게 없을 테니,

열심히 한 번 해보세요 :)

1. 코드가 200~250줄 정도 됩니다.

ㄴ 컬럼이 많은것일뿐 해석하려면 그냥 컬럼을 없애고 보기 시작해야합니다. *로 보면 됩니다.

2. 총 15개가량의 테이블을 조인해야 합니다.

ㄴ 메인 테이블 맨위에것 부터 조회하면서 데이터 확인 하면서 한개씩 조인 걸어가면서 데이터 확인하기 시작합니다.

3. 어떤 테이블은 그냥 join 했고 나머지 테이블은 left out join을 했는데 이유를 모르겠습니다.

ㄴinner join 은 일치해야만 나오게 할때 쓰는거구요, left out join 은 왼쪽 테이블에 데이터가 있는데 오른쪽 테이블에 데이터가 없더라도 표시하게 하기 위함 이구요. inner join 하면 해당 데이터(행)이 안나옵니다.

4. FROM문 안에 서브쿼리와 뷰가 들어있어서 읽으려고 노력해도 이해가 되지 않습니다.

 ㄴ 분리해서 읽어서 해석해야합니다. 메인테이블 중심으로 해석해야합니다.

흠.. 신입이시니 당황스러우시겠네요.

일단 제가 보기에는

그냥 간단한 쿼리입니다.

이정도면 아마 자기네들 기준 sql 표준 포맷에 잘 맟쳐서 한거 같고..

업무로직이 쿼리에 녹아있는것도 아니고..

이정도면 심플한거에요.

sql 문법이 이해되진 않는거 아니실거고..

너무 두려워하지 마시고.. 조인되는 테이블이 어떤 업무테이블인지

먼저 파악하시고 하나씩 조인해가면서 파악해보세요..

테이블명세서 같은 문서나 ERD도 찾아보면서.. 가급적 동원가능한 모든 관련문서도

보면서 천천히 하나씩 푼다고 생각하고 하세요.

레거시쪽 짜증나는 업무쿼리는 만라인 넘어가는것도 흔합니다..

첫 뉴비들이 힘든부분이 있습니다.

너무 막연해서 막막한 감정에 좌절하면서 손을 놓는 경우인데요..

뭐든 하나씩 시작이라도 하는게 중요합니다.

그럼 화이팅하시길...

쉬운쿼리라 조인만 이해하고 3일 공부하면 될듯

이정도면 쉬운 쿼리에 속합니다.

이건 그냥 학부생 수준이에요..ㅠㅠ

독학중인사람인데

별로어려워보이진않은데요.

그냥조인만줄줄이로달렸을뿐인뎅

쿼리가  길다고 좋은게 아닙니다.

한방쿼리로 한다고 화면과 백엔드균형을 무시하면

힘들어 집니다.

코드 질이 좋고 나쁨을 떠나서 

저런 쿼리는 한번에 똭 작성하는게 아니고

테이블 1개 조인 걸고 결과 확인하고 

그걸 가지고 

다른 테이블 걸고 결과 보고 이런식으로 

절차적으로 하는게 보통일겁니다.

저 쿼리 만드는 시간도 꽤 걸렸을지도 모를일이에요. 

근데 저렇게 만들면 나중에 변경사항생기면 
저 쿼리도 바꿔야 할때가 있을지도 모르는데 
그땐 헬파티 열리는겁니다. 

모든 코드가 저 쿼리에 의존 되어 있을거 거든요. 

다른 부분도 모두 바꿔야 한다는 소리죠. 

1. 절반정도가 select 컬럼이네요.  단순한쿼리에속합니다.

2. 좀많긴한데 복집하게 join걸린건 아니라서..

3.오키의 회원목록과 해당회원이 처음으로쓴게시글을 출력하는 쿼리뮨을 작성할때를 생각하시면됩니다.

일반조인은 게시글을 쓴회원만 출력되고

LEFT OUTER JOIN은 게시글을 안써도 회원목록에는 표시되지만 게시글항목이 null 로 출력되겠죠

4. 서브쿼리와 뷰는 데이터를 좀더 정리한 또하나의 테이블로 보시면됩니다.

대부분 코드테이블 조인(Left outer join) 해서,  이름(_nm)을 가져오는 부분이네요.  

이름 가져오는부분 빼고, 하나하나 쿼리를 쪼게서 분석해보세요.

사실 이건 단순한 쿼리입니다.

단지 연관이 된 테이블 수와 컬럼 수가 많아 읽기 불편한 것입니다.

SELECT절에 있는 단순 조회성 컬럼명들은 그냥 다 빼고 분석하세요.

괄호 안의 쿼리부터 분석하고,

그 괄호 안의 내용을 하나의 테이블로 보고

바깥쪽으로 시야를 넓혀가면서 분석하시면 됩니다.

LEFT OUTER JOIN (줄여서 LEFT JOIN) 은 외부조인이라 합니다.

이 JOIN구문 좌측에 배치하는 테이블명을 기준으로 조인을 하되

우측 테이블명의 테이블 데이터는 조인대상 데이터가 없어도 조회가 되게끔 (NULL들어감) 하는 겁니다.

(이건 교과서나 서적 설명 참고하세요. 저보다 쉽게 설명하는 분 많을 거에요.)

진짜 어려운 쿼리는

1. GROUP BY가 존재하는 경우 (물론 SELECT절에 수많은 그룹함수가 같이...)

2. CONNECT BY가 존재하는데 계층형 쿼리가 아닌 경우

   (단순 반복데이터 출력을 위해 궂이 CONNECT BY를 억지로 갖다 쓴 경우)

3. 조회하려는 테이블들이 정규화가 제대로 안되어 있는 경우

4. 테이블 인덱스가 제대로 안잡혀있어서 잘못 수정하면 조회성능이 확 떨어지게 되어있는 경우

3. PL/SQL인데 IF와 FOR 등으로 인덴트가 여러겹 중첩으로 되어있는 경우

그리고 회사코드는 사실 함부로 올리면 안됩니다.

이정도는 글펑도 OK요

그보다 회사자산을 캡쳐해서 올린다? 해고사유입니다. 일부 모자이크라도요. 절대로 하지마세요

윗분 말대로 복잡해 보이는 단순한 쿼리입니다.  조인 문만 이해하면 되는 레벨 입니다.

진짜 헬쿼리에 비하면 저정도는 아주 양호한 쿼리입니다..

줄도 이쁘게 잘 맞춰놨네요.

이런 코드 스타일이 좋다 나쁘다를 떠나서 이정도는 읽을 수 있어야 한다고 봅니다.

FROM 절에 오는 주 테이블부터 시작해서

join 걸리는 테이블 하나하나 추가하는 식으로 천천히 살펴 보셔요

선배님들 조언 감사드립니다. 선배님들이 말씀해주신대로 하나하나씩 찾아 이해하면서 sql 공부하겠습니다.