개발자인가 설계자인가

오라클 프로시져 작성시 중간중간 예외처리를 해야 하는 경우가 있습니다 

아래 내용을 다 쓰진 않지만 참조하시면 좋을것 같습니다.

오래된 버전이라 최근 것은 없지만 참고는 될듯 합니다.

sheet1(Hint-1) 은 용도로 정렬 

sheet2(Hint-2) 는 abc 순으로 정렬

첨부파일 다운로드 　

지난번 

[SQL]#1. SQL 작성순서?

에서는 SQL을 작성하는 순서를 얘기했었다 

#1 의 마지막에 

SQL을 작성하기 어려운 두가지 문제를 말했었다.

물론 두가지 보다 더 많은 이유가 있지만 가장 원인이 되는 두가지를 살펴 보자 

(이 두가지 이외에 다른 문제들도 다뤄 본다.)

 ** 단순 조인은 할 수 있다는 전제로 설명 **

1. 원하는 데이터가 TABLE 로 없다...

이게 무슨 말인가 하면 

우린 기본적으로 DML을 안다. 그러니 우리가 원하는 Column이 특정테이블에 있다면 

SQL을 작성하는데 아무 문제가 없다.

근데 현실은 그렇지 않다. 예를 들어 

T1 테이블에 매출 데이터가 있다고 가정하자. 당연히 판매일자 , 판매처, 품목, 수량, 단가, 금액등이 있을것이다 

(조회 기준 : 판매일자 >= 20191101 & 판매일자 <=20191130) 

실제로 조회는 이렇게 단순히 하는게 아니라 

[[11월 판매 데이터와 각 판매처 별로 11월 이전 가장 최근 데이터를 구하고 또

평균 구매간격과, 총 구매금액을 같이 조회 ]] 하고 싶다면..

단순히 select * from T1 으로는 안된다.

지금 여기서 말하고 싶은건 단순히 어떤 기술적인 요소를 말하고 싶은게 아니다. 

본인이 말하고 싶은건 @1 이럴때 우린 어떤 사고방식을 가져야 하는가? or 어떻게 접근해야(생각해야) 하는가?? 이다.

이 @1 부분이  sql 작성시에 초급 개발자들을 막막하게 하는 것이다.

본인은 이렇게 권한다.

1. 아래와 원하는 데이터가 있는 그렇게 생긴 테이블이 있다고 가정을 하라 ( Excel 등에 적어 두는걸 권장) 

   가상의 테이블 이름도 지어주자. 여기선 PT1.

2. T1과 PT1의 조인 관계를 생각해 보자

PT1은 판매처별로 데이터가 있다 그러니 T1과의 조인은 판매처만으로 조인이 될것이다. 

3. 그럼 우린 [[ ]]  를 작성하는게 아니라 PT1을 작성하는 셈이 되는것이다. 

PT1만 작성할수 있다면 결국 T1과 조인만 하면 [[ ]]  내용이 완성 되는 것이니까.

PT1의 내용이 이렇게 단순하지 않다면 ?? 다시 PT1-1 , PT1-2 , PT2 등을 분리하여 생각 하면 그만이다.

우리는 이 PT1.. 등을 생각해 내는걸 "집합적인 사고방식" 이라고 한다. 

이게 된다면 SQL 작성의 80%는 끝난 것이다. 

4. 속도는요? 

일단은 속도를 신경쓸 겨를이 없지 않은가? 걷지도 못하는데 날려고 하는 꼴이다.

2. JOIN의 개념을 모른다.

JOIN을 아는가, 모르는가 의 얘기를 하려는 것이 아니다. 

JOIN 할때 어떤 부분을 생각하고 고민해야 하는지를 말하려고 한다.

1. JOIN은 곱하기다. 

T1 에 2개의 ROW가 있고 T2에 4개의 ROW가 있다면 아래와 같이 아무 조건없이 

SELECT COUNT(*) FROM T1, T2 

이렇게 쿼리를 한다면 결과는 8 이다 .  당연하다 JOIN은 곱하기 이고 

조건이 없고 각 테이블에 2개의 로우가 있으니 2x4=8

이말은 어떤 COLUMN으로 서로 조인했을때도 동일하다. 

이 곱하기 되는 부분을 고민 해야 한다. 

2. 누가 메인이야? 

T1, 과 T2 에서 어느 테이블이 주 테이블인가? (어느 테이블이 더 중요한가) 

예를 들어 

T2는 무조건 나와야 한다면 OUTER 는 T1이 되는 것이다 .

SELECT T2.KEY, T2.CODE, T2.NAME , T1.NAME

FROM  T2 LEFT JOIN T1 ON T2.KEY = T1.KEY 

위 SQL을 해석하면  "행 기준으로!! T2는 무조건 나오고 T1 은 있으면 나오고 없으면 말고" 라는 뜻이다. 

그러니 T2.KEY 에 있는 값이 T1.KEY 에 없다고 하더라도 무조건 나오게 된다. 

사실 Join은 이보다 더 어려운 개념이지만 위의 두가지 개념을 확실히 해야 다음으로 넘어갈 수 있다.

3. 다른건 없나요?

다른 요인도 많지만 위의 1,2 항목이 가장 기본이라 할 수 있겠다 

참고로 몇가지 더 말해보면 

1. 함수 및 문법 숙지 : 각 DBMS에서 제공하는 함수와 그 사용처 문법을 숙지 하는것

2. 많이 작성해 볼것 : 말할것도 없다.

3. 자신만의 SQL 사전을 관리 할 것 : 인테넷에 많이 있지만 본인만의 설명으로 본인이 이해할수 있는 sql 사전을 만들면 좋다. 

 4. 동일한 결과를 분석함수를 쓸때와 안쓸때를 구분해 볼것.  : 분석함수는 각 DBMS에서 제공해주는 매우 유용한 함수이지만 분석함수를 쓰지 않고 동일한 결과를 만들어 내는 연습을 하면 SQL 작성에 많은 도움이 된다.

5. 옵티마이져가 되어 볼것 : 우리가 SQL을 작성하고 실행하면 각 DBMS의 옵티마이져가 이를 분석/해석하고 처리하게 된다. 그 역할을 상상하고 되어 보는것도 매우 많은 도움이 된다.

6. 테스트 테이블을 가질것 : 자신만의 테스트 테이블을 가지는게 좋다 부분 부분의 sql을 작성해볼 수 있는 테스트 테이블을 통해 실제 결과를 눈으로 확인하면서 SQL을 작성해 본다 

7. 주석의 관리 : SQL도 주석을 달 수 있다. 다음 운영자를 위해서라도 주석을 꼼꼼히 다는 습관을 지녀야 한다.

8. 지난 SQL 검토 : 예전에 작성한 SQL을 검토해 본다 (당시 작성할때 고생했던 SQL들) ... 뭐 해보면 알것이다.

이상 SQL의 작성 순서와 작성시 왜 어려웠는지 알아봤다.

근데...결국은 스스로 해보고 답을 찾아야 한다. 

위에 작성한 내용 역시 그렇게 찾은 결론이다. 

정답이 아닐수 있겠고 정말 SQL을 잘 하시는 선수들이 보면 뭐라 할지 모르겠다 ㅎㅎ 

그럼 이만~ 

SQL 을 작성하면서 DML , DDL, DCL, TCL 이런 용어를 알아야 하는가? 라고 묻는다면 ... 

"뭐 꼭 그럴필요는 없다." 라고 말한다. 

근데 SQL을 작성해야만 하는 개발자라면 저런 용어는 알아두는게 좋다. 

DML : Data Manipulation Language

쉽게 설명 > SELECT, UPDATE , INSERT , DELETE , MERGE 등..

풀어서 설명 > 우리가 일반적으로 "쿼리를 짠다" , "SQL을 작성한다" 이런것들을 말한다. 

근데....DML 에서 M 이 Manipulation 인건.....솜씨있는 처리로 쿼리를 짜라는 소린가??..ㅎㅎ 

DDL : Data Definition Language

쉽게 설명 > CREATE, ALTER, RENAME, DROP, TRUNCATE,  등..

풀어서 설명 > 객체(테이블, 뷰, 프로시져 등등)를 생성하거나 수정하거나 지우거나 할때 사용하는 Syntax

DCL : Data Control Language

쉽게 설명 > GRANT, REVOKE 등..

풀어서 설명 > 권한을 주거나 회수 하기위한 Syntax. 권한이란 접근 및 조회, 수정 권한 등을 말한다.

TCL : Transaction Control Language

쉽게 설명 > COMMIT, ROLLBACK, SAVEPOINT 등..

풀어서 설명 > 입력(Insert), 수정(Update), 삭제(Delete) 된 데이터는 사실 현재 본인의 세션에만 적용이 된것이라 생각하면 된다. 좀 더 깊게 파고들면 할말이 많은데 ... 일단은 이렇게만 알아두자 (깊게 파면 깊어짐)

여튼 현재 C,U,D 된 데이터를 DB(Table)에 "빡! 적용하라"..고 하는 명령어가 COMMIT, 

"응, 아니야 되돌려놔" 라고 하는 명령어가 ROLLBACK, 

"특정 위치까지만 되돌려놔" 라고 하는 명령어가 SAVEPOINT 이다.

SAVEPOINT 를 조금만 더 설명 하자면.....(아주 조금만.)

요렇게 하고 

SAVEPOINT pointForRollback1;

SAVEPOINT pointForRollback2;

요렇게 하면

ROLLBACK TO pointForRollback1;

pointForRollback1 지점까지만 Rollback이 되는거다...

그니까....pointForRollback1 다음부터 pointForRollback2 전까지 작업한 내용은 날라간다는것.

참고로 SQL은 Structured Query Language 의 약자이다

DB 란 무엇인가.

Database 의 약자인 DB는 

쉽게말해 정보의 집합체 이다.

그럼 정보는 무엇일까? 세상의 온갖것들이 다 정보이다.

그럼 그 모든것들을 다 Data 라고 봐야하나? 그건 아니다. 

설계자로써 가져야 하는 기본 마음 가짐은 "의미없는 컬럼은 없다" 이다. 

예를들어 내가 어떤 음식을 좋아하고 어떤 게임을 즐겨하며 직원들과 몇번의 술자리를 갖는지 

가족관계는 어떻게 되고 우리 가족은 휴일에 무엇을 하는지 

이런 것들은 일종의 정보일수는 있지만 Data라고 볼 수 없다. 

Data란 "구축된.. 또는 구축되어야 하는 System에서 필요로 하는 정보" 이다.

고객들과의 분석 과정에서 우린 수많은 요구사항을 듣는다. 

물론 고객들은 필요한 것들을 요구한다.

하지만 우린 제한된 Resource 안에서 수행할 수 밖에 없고 

고객의 모든 요구가 Programming 적으로 합당한지 검토할 수 밖에 없다. 

또한 그안에서 품질(Quality) 가 나와야 한다.

그렇다면 분석/설계자 (이하 설계자) 무엇에 초점을 맞추고 진행해야 할까? 

지극히 개인적인 생각이지만 역시 한줄로 표현하면 

"의미없는 컬럼은 없다" 이다.

"컬럼(Column)"은 Data의 최소 단위 이다. 이 컬럼들이 모여서 

데이터의 집합체-테이블(Table)이 된다. 또 그 테이블이 모여 고객이 원하는 시스템의 

데이터베이가 되는것이다.

설계자는 이 컬럼의 필요성과 연결고리를 고려해야만 한다. 

또한 사용처를 고민하지 않을 수 없다. 컬럼은 전체적인 공수나 프로그램 수정에 직접적인 영항을 주기 때문이다.

예를들어 고객사의 현업 A씨는 '도착예정일자'가 필요 하다고 한다. 

이유는 단순히 예정일자를 관리하고 싶어서 이다.

이건 현업의 언어이다. 설계자는 저 요구사항에서 일단 컬럼을 생각한다. 

표준에 맞는 DB타입, 개발 언어나 공통에서 제공하는 부분이 있는지.. 

현재 Table 에는 있는지 등등 ... 근데 더욱 중요한건 

업무적으로 어떻게-어디서 쓰이느냐 또 다른 화면에 영향이 있는가 이다.

생각나는데로 몇가지 얘기해 보면 

- 검수 등의 스케쥴을 관리해야 하는가?

- 예정일자로 인해 스케줄 관리가 추가될 가능성이 있는가? 

- 현황을 보는 레포트에서 추가가 필요한가? 

- 현황을 보는 레포트가 없다면 레포트가 추가될 가능성이 있는가? 

- 날짜에 대한 계산을 해야하는 것인가? 

- 현재 화면(업무)을 참조하는 다른 화면에서는 필요하지 않은가?

- 예정일자가 지난 경우 어떻게 처리가 될것인가?  Alert 기능이 필요한가?

- 예정일자가 도래하고 있는경우 어떻게 처리해야 하는 것인가? Alert 기능이 필요한가?

- 현재 화면에 예정일자에 대한 조회 조건을 추가해야 하는것인가? 

- 프레임웍에선 어떻게 조회조건을 받고 있는가?

 등등 ... 

고객은 단순히 "도착예정일자가 필요해요" 한마디 한건데 너무 오버 한다고 느껴지는가? 

본인은 그렇지 않다. 실제로 많은 현업들은 지금 생각나는것을 말한다. 

더 실력이 좋은 현업들은 다음,, 그 다음 요구하기 위해 현재의 것을 요청한다. 

최종적으로 요청할 화면 또는 프로세스가 너무 커지므로 조금씩 구현 시켜놓는 것이다. 

고객의 요구를 무시하자는 말이 아니다. 

거의 대부분의 요구에는 컬럼이 필요하고 설계자가 그것을 어떻게 받아 들이는지가

일정과 직접적인 연관이 있으니 이런 작은 쨉(?) 들을 단순하게 받아들이면 안된다는 것이다. 

설계자는 언제나 고객요구사항-일정-개발자-품질 의 한 가운데에 있다.

정해진 기일까지 최상의 품질로 모두를 만족 시켜야 하는 그런 어려운 일을 하고 있다.

그런 설계자 이기에 항상 모든 요구 하나하나에 무게를 두고 일을 해야한다. 

SQL, 우리가 쿼리를 짠다고 하는 .. 그 SQL.

SQL의 작성 순서는 어떻게 될까? 

쿼리 좀 짠다는 사람들은 "쿼리는 집합적 사고방식을 가져야 한다." 라는 말을 

몇번씩 들어 봤을 것이다. 

본인 역시 공감한다. 

단순한 쿼리야 뭐 어떻게든 작성할 수 있지만 

당장 테이블 3,4 개 이상만 조인을 하게 된다고해도 "집합적" 인 사고방식이 아니고서야 

작성 자체가 힘들어 하는 쿼린이들이 있을 것이다.

나보다 더 훌륭한 쿼리 고인돌들이 이글을 보면 뭐라고 할지 모르겠지만 

가장 첫 번째로 생각할 것은 

내가 가져오려고 하는 데이터가 어디에 있는가? 이다 

예를 들어 내가 Select 해야하는 컬럼의 갯수가 20 라고 가정할때 

저 20개 컬럼이 한 테이블에 다 모여 있다면 ?? 매우 Happy 하다. ㅎㅎ

근데 이런일은 없다 ㅠㅠ 

어지간한 데이터 건수가 아니면 집계테이블도 없고 

설사 집계테이블을 생성할 수 있다고 해도 집계테이블의 특성상 

언제나 비동기적이기 때문에 생성 자체를 고민해야 하고 ...

여튼...이건 설계 문제이니 다시 본론으로 돌아와서 

20개의 컬럼이 어디에 분포 되어 있는지를 찾는다.....가 첫번째 할일이다

이를 SQL로 본다면  SELECT * FROM T1, T2, T3, T4, T5 에 해당 될것이다. 

주의점은 SELECT 는 * 로 거들뿐 지금 단계에서는 고민 하지 않는다.

두번째는 이  T1 ~ T5 를 어떻게 연결(JOIN) 할 것인가? 이다. 

이부분은 WHERE 절에 해당 되는 내용이다. 

그러면 남은건? SELECT 에 원하는 20 컬럼을 잘 선택해서 사용 하면 되는것.  이게 세번째 ... 

근데 왜? 쿼리짜는걸 어려워 할까?  쉬운데....

나 어렸을적.. 43분마다 혼나던 시절을 떠올려 보면 

결국 두가지다

1. 원하는 데이터가 TABLE 로 없다...

모든 데이터가 단순히 테이블 조인으로 연결이 된다면 어려울리가 없겠지..

근데 실상은 그렇지가 않다. 

그러니 이 테이블을 SQL상에서 임시로 만들어야 하는 경우가 생긴다. 

이럴때 집합적인 사고방식이 필요하다는 것. 

2. JOIN의 개념을 모른다.

테이블(임시 테이블 포함) 간의 조인을 하는 부부이 어려웠다 

특히 OUTER JOIN과 INNER JOIN

근데 이건 뭐 일단은 공부하고 외우는 수밖에 없다. 

좀더 고급진 조인은 그 다음 문제...

그럼.... 저 두가지 문제를 어떻게 해결 해야 할까? 

그 방법은 다음에 작성하도록 한다.   뿅