주로 MSSQL 쪽 프로그래밍을 하다보니.. 여러가지 내부적인 것들을 건드리게 되는군요.
<그림 1 - 기본>
위 그림은 일반적인 블록 주석문과 라인 주석문에 대한 구문이고..
단순한 수행 쿼리입니다.
수행해 보면 결과가 정상적으로 1 이 나옵니다..
그렇다면 아래 2번 그림의 쿼리는 어떨까요?
<그림 2 - 먼가 다른 주석처리>
프로그래머 관점이라면 저기 붉은 사각박스의 /* 가 하나 더 들어갔다고 해서..
위 그림처럼 주석 처리가 되면 안되겠지요..
수행하면 당연히 에러를 토해냅니다.
메시지 113, 수준 15, 상태 1, 줄 5
주석 끝 표시('*/')가 없습니다.
사실 의도된 결과는 아래 그림처럼 나오길 바랬습니다.
<그림 3 - 내가 원했던 결과>
자 그렇다면 MSSQL에서는 그림 2번과 그 결과처럼 /*는 페어처리를 하도록 설계된 것인가?
그림 2번 내용을 조금 바꾸어 보도록 하죠.
<그림 4 - 이제서야 보이는 설계 의도>
<그림 5 - mssql 2008 ssms> <그림 6 - msvs 2008>
지금 까지 여러가지를 테스트해본 결과.. 쿼리를 고속으로 파싱해야 하는 sql 엔진 입장에서
내부적으로 다중 중첩된 블록 주석문을 처리하는것이 상당히 부담스러웠던거 같습니다.
첫번째 의견은 위와 같았는데.. 실제로 구현이나 파싱처리에서 보면 sql 처럼 처리하는게
로직적으로 더 부담이 되겠네요. 주석의 끝을 명시해야 하는것도 그렇고..
아마도 스크립트로 의도되지 않은 동작을 일으키지 못하도록 방어하는 입장에서 작성된거라 생각듭니다.
그래서 블록 주석문은 /*의 갯수가 나오면 기존 블록에 포함되던 말던.. 나온 갯수 만큼 */ 의 페어를
맞추어 주로록 의도적으로 설계된듯하네요..
어쨋든 저렇게 의도 되었다는 것을 알게는 되었지만..
일부 로직을 새로 짜야한다능.. ㅠㅠ
오늘의 팁하나..
MSSQL에서 tempdb에 임시테이블을 만들고 통계를 작성하면, 거기서 작성된 통계를
오리지날 테이블에 업데이트 시킬수가 없다.
콜레이션 문제가 발생하기 때문이다.. 끝~