패딩
아웃도어 추천 
http://todayhumor.com/?bestofbest_190553   (정보공유7탄. 패딩을 찾아서. BGM 사진겁나많음.)(우리헤어졌어요님 글)



블루종/스타장
프리즘웍스 http://www.frizm.co.kr/



코트
지오지아 https://www.ziozia.co.kr/   (백화점)
커스텀멜로우 http://www.customellow.com/


니트/가디건
지오다노 http://giordano.co.kr/  
포레스트캠프 http://www.forestcampshop.com/
더니트컴퍼니 http://theknitcompany.co.kr/
하우트옴므 http://hauthomme.com/
울오버 http://www.woolovers.com/     (해외 직구)


티셔츠/맨투맨
지오다노 http://giordano.co.kr/  
스파브랜드로 대부분이 기본맨투맨 
↓스트릿브랜드들로 디자인이 가미된 맨투맨
드리프트아웃 http://www.driftout.co.kr/



셔츠

청바지 



치노/슬랙스
지오다노 http://giordano.co.kr/  

무지티

양말


기타 인터넷 쇼핑몰
자비노 www.zavino.co.kr


PIVOT

PIVOT의 사전적 의미는 축을 중심으로 회전(선회축)한다는 의미이다.

SQL적으로 보면 컬럼을 반시계 방향으로 회전해서 각각의 컬럼으로 사용하겠다는 것을 뜻한다.


그림으로  표현하면 이렇지 않을까?ㅋㅋㅋ


피벗테이블을 사용하는 이유는 다음과 같다.


데이터를 요약, 분석, 탐샙 및 표시하기 위해서

필요한 데이터만 뽑아서 새롭게 테이블을 작성하기 위해서

목록을 단순한 형태로 요약하기 위해서


위의 예는 엑셀에서 피벗테이블을 사용하는 방법인데 SQL에서도 이유는 비슷할것이다.

피벗 문법에서 집계함수를 사용하는것도 이와 같은 이유때문이다.

문법

PIVOT 

집계함수(컬럼명) --오른쪽으로 회전할 컬럼명(같은 그룹끼리 집계)

FOR [위로 올릴 컬럼] IN (FOR에서 사용한컬럼명중 사용할 컬럼 도메인목록) 

) AS 피벗 Alias


집계함수를 사용하는 이유는 위에서 설명했다.

FOR_IN_구문은 FOR은 회전시킬 컬럼 IN 회전시킬 컬럼 도메인정도로 이해하면 된다.

이렇게 회전을 하게되면 집계함수 값들은 한 행이될것이고, 그 이외의 값은 자동으로 GROUP BY되어서 하나의 행이 만들어 진다.



UNPIVOT은 그 반대가 된다. 선택한 컬럼명들이 반대로 회전하겠지? 


UNPIVOT 

컬럼명 --왼쪽으로 회전시킨 컬럼들을 이름 지을 컬럼명

FOR [오른쪽으로 회전한후 이름지을 컬럼명]

IN (회전시킬 컬럼들) 

) AS 피벗 Alias


이제 예를 들어서 살펴보자.

예제

다음과 같은 임시테이블을 사용할 것이다.

이 테이블에서 월별로 합을 구한뒤 이를 PIVOT과 UNPIVOT으로 회전시켜볼것이다.


SUM을 구해보자



이제 PIVOT을 통하여 테이블을 회전시켜 보자


결과는 다음과 같이 나온다. MONTH의 열에 있는 값을 컬럼으로 올리고, SUM을 각 열로 둠으로써 테이블을 회전시켰다.



다음으로 UNPIVOT을 사용하여 한번더 회전 시켜보도록하자.



이처럼 테이블을 시계방향으로 계속돌리면 결과적으론 컬럼이 반대로 나온다.


PIVOT과 UNPIVOT을 동시에 사용할 일을 잘 없지만, 예제를 위해서 작성해 보았다.




참조링크 (동적쿼리와, PIVOT)

'SQL > MS-SQL' 카테고리의 다른 글

단위처리  (0) 2017.11.02
Datetime Fomat  (0) 2017.10.11
제약 조건(Constraint) #2 (기존 테이블에 추가/삭제)  (0) 2017.09.20
제약 조건(Constraint) #1 (의미와 설정)  (0) 2017.09.20
테이블변수  (0) 2017.09.20

0. 들어가기에 앞서...


각 제약조건의 의미와 테이블 생성시 제약조건을 설정하는 방법들에 대해선 "제약 조건 #1" 문서를 참고하자.

위 문서에서 SSMS를 이용하여, 제약조건을 설정하는 방법은 테이블을 만들고 나서도 자유롭게 추가/삭제가 가능하다.
하지만, 위 문서의 T-SQL을 이용한 방법은 테이블을 생성할 때의 내용뿐이었다.

이제 T-SQL을 이용하여 이미 존재하는 테이블, 그것도 대량의 데이터가 들어있는 테이블에 대해
새로이 제약조건을 추가하거나, 기존의 제약조건을 변경, 또는 삭제하는 방법을 알아보도록 하자.

기존의 테이블을 변경하는 기본 구문은 ALTER TABLE이며, 이에 대해선 이 챕터에서 자세히 설명하진 않는다.


1. 제약 조건의 추가

제약조건을 추가하는 기본 구문은 ADD CONTRAINT constraint_name이며,
이는 아래 예제들에서도 반복적으로 나오므로 자연스레 눈에 익을 것이라 생각한다.

ADD CONSTRAINT constraint_name과 각 제약조건의 종류에 따른 키워드들로 제약 조건 추가 구문이 조합된다.


1. PK 제약 조건

기본 키가 지정되어 있지 않던 테이블에 기본키를 추가하는 방법은 아래와 같다.

  1. ALTER TABLE UserTable
  2.     ADD CONSTRAINT PK_UserTable_ID
  3.     PRIMARY KEY(UserID)

    기존 테이블에 PK를 추가하려 할 때, 해당(UserID) 컬럼은 NOT NULL로 설정이 되어 있어야 한다.


    2. FK 제약 조건

    기존 테이블에 FK(외래 키)를 설정하는 방법은 아래와 같다.

    1. ALTER TABLE BuyTable
    2.     ADD CONSTRAINT FK_UserTable_ID
    3.     FOREIGN KEY (ID)                  -- 이 테이블에서 FK를 걸 컬럼명
    4.     REFERENCES UserTable(UserID)      -- 기준 테이블의 참조 컬럼명

    이미 데이터들이 꽤나 많이 차 있는 두 개의 테이블에 FK 의존 관계 설정시 애 먹는 경우가 있다.

    애초 의존 관계를 고려하지 않았기에, 기준 테이블에 존재하지 않는 데이터가 외래 키 테이블에 존재할 수 있기 때문이다.
    헌데, 이미 서비스 중이고, 대량의 데이터가 차 있기에, 모든 데이터의 의존 관계를 완벽하게 조정할 수도 없는 상태이다.

    이런 경우 ALTER TABLE 구문을 WITH NOCHECK 옵션과 함께 사용하면,
    이미 입력되어 있는 데이터의 무결성(의존 관계)를 무시하고 외래 키 관계가 설정된다.

    참고로, 아무 것도 써 주지 않을 경우 기본적으로 WITH CHECK 상태이다.

    1. ALTER TABLE BuyTable WITH NOCHECK
    2.     ADD CONSTRAINT FK_UserTable_ID
    3.     FOREIGN KEY (ID)                  -- 이 테이블에서 FK를 걸 컬럼명
    4.     REFERENCES UserTable(UserID)      -- 기준 테이블의 참조 컬럼명

    WITH NOCHECK 옵션은 FK와 CHECK 제약 조건에서만 설정이 가능하다.

    그리고 WITH CHECK / WITH NOCHECK 옵션은 
    제약 조건을 생성할 때 기존의 데이터를 검사하는 것을 무시하는 것일뿐설정한 후에는 당연히 제약 조건이 작동됨을 혼동하지 말자.


    3. UNIQUE 제약 조건

    기존 테이블에 UNIQUE 제약 조건을 추가하는 방법은 아래와 같다.

    1. ALTER TABLE UserTable
    2.     ADD CONSTRAINT UK_Regdate
    3.     UNIQUE RegDate


    4. CHECK 제약 조건

    기존 테이블에 CHECK 제약 조건을 추가 설정하는 방법은 아래와 같다.

    1. -- 출생년도가 1900년 이후 그리고 현재의 연도 이전
    2. ALTER TABLE UserTable
    3.     ADD CONSTRAINT CK_BirthYear
    4.     CHECK (BirthYear >= 1900 AND BirthYear <= YEAR(GETDATE()))
    5.  
    6. -- 전화번호 국번 체크 (아래 번호들 중에서만 가능)
    7. ALTER TABLE UserTable
    8.     ADD CONSTRAINT CK_Mobile1
    9.     CHECK (Mobile1 IN ('010''011''016''017''018''019'))
    10.  
    11. -- 키는 0 보다 커야 함
    12. ALTER TABLE UserTable
    13.     ADD CONSTRAINT CK_Height
    14.     CHECK (Height > 0)


    5. DEFAULT 정의


    기존에 없던 DEFALUT 정의를 추가하려면 아래와 같이 FOR 문을 함께 사용해 주어야 한다.

    1. ALTER TABLE UserTable
    2.     ADD CONSTRAINT CD_BirthYear
    3.     DEFAULT YEAR(GETDATE()) FOR BirthYear
    4.  
    5. ALTER TABLE UserTable
    6.     ADD CONSTRAINT CD_Addr
    7.     DEFAULT N'서울' FOR Addr
    8.  
    9. ALTER TABLE UserTable
    10.     ADD CONSTRAINT CD_Height
    11.     DEFAULT 172 FOR Height



    2. 제약 조건의 삭제

    기존의 제약 조건을 삭제하는 것은 추가하는 것에 비해 무척이나 간단하다.
    제약 조건의 종류에 관계없이 공통된 구문 하나로 모두 적용이 가능하다.

    1. ALTER TABLE tableName
    2.     DROP CONSTRAINT constraint_name

    만약, 제약 조건만 삭제하는 경우가 아니라, 해당 컬럼을 삭제하려 하고 그 컬럼에 제약 조건이 걸린 경우라면,
    1. 제약 조건을 먼저 삭제하고,
    2. 해당 컬럼을 삭제해야 한다.

    즉, UserTable의 BirthYear에 CHECK 제약 조건이 걸려 있는데, BirthYear 컬럼을 삭제하고 싶으면,
    아래 예제와 같이 CHECK 제약 조건을 먼저 삭제한 후에 컬럼을 삭제해야 하는 것이다.

    1. -- 먼제 BirthYear에 걸려있는 제약 조건을 삭제하고
    2. ALTER TABLE UserTable
    3.     DROP CK_BirthYear
    4.  
    5. -- BirthYear 컬럼을 삭제해야 한다.
    6. -- DROP COLUMN column_name 형식에 주의하라
    7. ALTER TABLE UserTABLE
    8.     DROP COLUMN BirthYear


    3. 제약 조건 활성/비활성화

    위에서 WITH CHECK / WITH NOCHECK 옵션은 
    제약 조건을 생성하는 그 순간에서만 제약 조건 체크를 스킵할 지 여부를 결정하는 것이라 하였다.

    그럼, 이미 만들어진 제약 조건을 잠깐 비활성화하고 싶을 때는 어떻게 해야 하는가?

    CHECK CONSTRAINT / NOCHECK CONSTRAINT 옵션을 사용하면 된다.
    • CHECK CONSTRAINT constraint_name : 특정 제약 조건을 활성화
    • NOCHECK CONSTRAINT constraint_name : 특정 제약 조건을 비활성화
    • NOCHECK CONSTRAINT ALL : 모든 제약 조건을 비활성화

    1. -- FK 일시적으로 비활성화
    2. ALTER TABLE BuyTable
    3.     NOCHECK CONSTRAINT FK_UserTable_ID
    4. GO
    5.  
    6. -- FK 제약 조건에 위배되는 데이터 삽입
    7. INSERT INTO BuyTable VALUES (...)
    8. INSERT INTO BuyTable VALUES (...)
    9. INSERT INTO BuyTable VALUES (...)
    10. GO
    11.  
    12. -- FK 다시 정상적으로 활성화
    13. ALTER TABLE BuyTable
    14.     CHECK CONSTRAINT FK_UserTable_ID
    15. GO

    간혹, 써 먹어야 될 때가 있을 것이다.


    'SQL > MS-SQL' 카테고리의 다른 글

    Datetime Fomat  (0) 2017.10.11
    PIVOT/ UNPIVOT  (0) 2017.09.21
    제약 조건(Constraint) #1 (의미와 설정)  (0) 2017.09.20
    테이블변수  (0) 2017.09.20
    테이블 컬럼변경  (0) 2017.09.20
    1. 제약 조건


    제약 조건(Constraint)이란, 데이터의 무결성을 지키기 위해 제한된 조건을 의미한다.

    즉, 특정 데이터를 입력할 때 무조건적으로 입력되는 것이 아니라, 
    어떠한 조건을 만족했을 때에만 입력되도록 제약을 할 수 있는 것이다.

    예를 들어, 어떠한 쇼핑몰에 가입할 때 이미 가입한 주민등록번호로는 재가입이 되지 않는다.
    그 이유는 주민등록번호 열에 동일한 것이 들어갈 수 없는 "제약 조건"이 설정되어 있기 때문이다.
    이런 경우 주민등록번호에 중복이 불가능한 제약 조건(이 경우 보통 UNIQUE)이 들어 있을 것이다.

    이 외에도 SQLServer는 아래와 같은 제약 조건들을 제공하고 있다.
    • Primary key 제약 조건
    • Foreign key 제약 조건
    • UNIQUE 제약 조건
    • CHECK 제약 조건
    • DEFAULT 정의


    2. PK 제약 조건

    테이블에 존재하는 많은 행의 데이터를 구분할 수 있는 식별자를 "기본 키(Primary key)"라고 부른다.

    기본 키에 입력되는 값은 중복될 수 없으며, NULL 값이 입력될 수 없다.

    기본 키로 생성한 것은 자동으로 클러스터형 인덱스가 생성된다.


    1. CREATE TABLE UserTable
    2. (
    3.     UserID CHAR(8) NOT NULL PRIMARY KEY,
    4.     Name NVARCHAR(10) NOT NULL,
    5.     -- 이하 열 생략
    6. )

    이렇게 설정함으로써 UserID는 UserTable의 기본 키가 되었으며,
    앞으로 입력되는 UserID는 당연히 중복될 수 없고, 비어(NULL) 있을 수도 없다.

    모든 제약 조건은 이름을 가지게 되는데, 위와 같이 UserID 열에 대해 기본 키를 설정하고 나면,
    "PK__UserTable__3214EC27060DEAE8" 등과 같이 알아볼 수 없는 이름을 가지게 된다.
    이는 SQLServer가 제약 조건의 이름을 나름의 규칙을 가지고 알아서 설정해 버리기 때문이다.

    UserTable에 PK가 설정되었다는 것까지는 알겠는데, 위와 같은 네이밍이면 어느 열이 PK인지 알아보기 쉽지 않다.

    기본 키를 설정할 때 이름을 지정하려면 아래와 같이 CREATE TABLE시 작성하면 된다.

    1. CREATE TABLE UserTable
    2. (
    3.     UserID CHAR(8) NOT NULL CONSTRAINT PK_UserID PRIMARY KEY,
    4.     Name NVARCHAR(10) NOT NULL,
    5.     -- 이하 열 생략
    6. )

    UserTable의 기본 키를 UserID 열로 정하되, PK_UserID라는 이름을 가지도록 하라는 것이다.


    또한, 테이블에서 하나 이상의 열을 기본 키로 설정할 수 있다.
    즉, N 개의 열을 묶어 기본 키로 설정할 수 있는 것이다.

    SSMS에서 아래와 같이 복수의 컬럼을 엮어 기본 키로 설정할 수 있으며,



    T-SQL의 CREATE TABLE문은 아래와 같이 작성하여 복수 열을 기본 키로 설정할 수 있다.

    1. CREATE TABLE UserTable
    2. (
    3.     UserID CHAR(8) NOT NULL,
    4.     Name NVARCHAR(10) NOT NULL,
    5.     -- 이하 열 생략
    6.     CONSTRAINT PK_UserID_Name PRIMARY KEY (UserID, Name)  
    7. )


    3. FK 제약 조건

    외래 키(Foreign Key) 제약 조건은 
    두 테이블 사이의 관계를 선언함으로써, 데이터의 무결성을 보장해 주는 역할을 한다.

    외래 키 관계를 설정하게 되면 하나의 테이블(외래 키 테이블)이 다른 테이블(기준 테이블)에 의존하게 된다.

    '외래 키 테이블'에 데이터를 입력할 때는 꼭 '기준 테이블'을 참조해서 입력하므로,
    반드시 '기준 테이블'에 존재하는 데이터만 입력이 가능하다.

    또한, '외래 키 테이블'이 참조하는 '기준 테이블'의 열은 반드시 PK이거나 UNIQUE 제약 조건이 설정되어 있어야 한다.
    이는 조금만 생각해보면, 지극히 당연한 제약이다.
    A가 B를 참조하는 데 B가 여러 개 이면 어느 것을 참조해야 할 지 알 수 없기 때문이다.



    1. CREATE TABLE UserTable
    2. (
    3.     UserID CHAR(8) NOT NULL
    4.     CONSTRAINT PK_UserID PRIMARY KEY,
    5.     Name NVARCHAR(10) NOT NULL,
    6.     -- 이하 열 생략
    7. )
    8.  
    9. -- unnamed
    10. CREATE TABLE BuyTable
    11. (
    12.     UserID CHAR(8) NOT NULL
    13.     FOREIGN KEY REFERENCES UserTable(ID),
    14.     -- 이하 열 생략
    15. )
    16.  
    17. -- named
    18. CREATE TABLE BuyTable
    19. (
    20.     UserID CHAR(8) NOT NULL
    21.     CONSTRAINT FK_UserTable_ID FOREIGN KEY REFERENCES UserTable(ID),
    22.     -- 이하 열 생략
    23. )



    헌데, 외래 키로 지정한 기준의 컬럼의 값이 변경되면 외래 키 테이블의 컬럼 값은 어떻게 처리할 것인가?

    예를 들어, UserTable의 ID(PK) = 'KHD'인 값이 있고, BuyTable에도 ID(FK) = 'KHD'인 데이터들이 있다.
    ID 변경 아이템 등을 사용하여 UserTable의 ID 'KHD'를 'KKHD'로 변경해야 한다면, 
    BuyTable에 이미 존재하는 'KHD'들도 변경이 되어야만 외래 키 제약이 제대로 유지될 수 있다.

    외래 키 옵션 중 ON UPDATE CASCADEON DELETE CASCADE라는 것이 있다.
    • ON UPDATE CASCADE : 기준 테이블의 데이터가 변경되었을 때 외래 키 테이블도 자동으로 변경
    • ON DELETE CASCADE : 기준 테이블의 데이터가 삭제되었을 때 외래 키 테이블의 데이터들도 자동으로 삭제

    외래 키의 위 두가지 옵션에 대해 기본값은 ON UPDATE NO ACTION과 ON DELETE NO ACTION으로 지정되어 있다.
    즉, 기준 테이블의 데이터가 변경/삭제되어도 외래 키 테이블에 자동적으로 변경/삭제를 해주지 않도록 되어 있다.

    이를 변경하는 방법 역시 SSMS를 통한 방법과 T-SQL을 통한 방법 두 가지가 있다.

    먼저 SSMS의 속성은 다음과 같이 변경이 가능하다.



    기본적으로는 동작 안 함이 선택되어 있으며, CASCADE를 설정하고 싶으면 "계단식 배열"을 선택하면 된다.
    (번역 참 구리다)

    그리고 아래와 같이 작성하면 T-SQL을 통해서도 속성 변경이 가능하다.

    1. -- ON UPDATE CASCADE
    2. CREATE TABLE BuyTable
    3. (
    4.     UserID CHAR(8) NOT NULL
    5.     FOREIGN KEY REFERENCES UserTable(ID)
    6.     ON UPDATE CASCADE,
    7.     -- 이하 열 생략
    8. )
    9.  
    10. -- ON DELETE CASCADE
    11. CREATE TABLE BuyTable
    12. (
    13.     UserID CHAR(8) NOT NULL
    14.     CONSTRAINT FK_UserTable_ID FOREIGN KEY REFERENCES UserTable(ID)
    15.     ON DELETE CASCADE,
    16.     -- 이하 열 생략
    17. )


    4. UNIQUE 제약 조건

    UNIQUE 제약 조건은 중복되지 않는 유일함을 부여하고 싶을 때 사용하는 제약 조건이다.
    PK와 얼핏 비슷해 보이지만, 네 가지 차이점이 존재한다.
    • UNIQUE는 유일하게 하나의 개체에 대해서만 NULL을 허용한다.
    • PK는 테이블에 하나만 존재 가능하나, UNIQUE 제약조건은 여러 개 설정이 가능하다.
    • PK는 자동으로 클러스터형 인덱스가 된다.

    흔한 게임 DB의 유저 정보를 예로 들자면, 유저 식별 번호나 유일한 ID 등은 PK로 잡겠지만,
    사용자별 E-Mail 주소나 닉네임에 대해서는 UNIQUE 제약조건을 부여할 수 있는 것이다.
    이를 T-SQL로 설정하는 방법은 아래와 같다.

    1. -- unnamed
    2. CREATE TABLE UserTable
    3. (
    4.     -- ...
    5.     Email NVARCHAR(50) NOT NULL UNIQUE,
    6.     -- ...
    7. )
    8.  
    9. -- named
    10. CREATE TABLE UserTable
    11. (
    12.     -- ...
    13.     Email NVARCHAR(50) NOT NULL
    14.     CONSTRAINT UK_UserTable_Email UNIQUE,
    15.     -- ...
    16. )


    5. CHECK 제약 조건

    CHECK 제약 조건은 특정 조건들로 이루어진 수식을 통해 입력되는 데이터를 검증할 때 사용한다.

    예를 들어, 음수값은 허용하지 않는다던지,
    출생년도가 1900년 이후이고 현재 시점 이전이어야만 한다던지 등의 조건을 지정할 수 있는 것이다.
    이를 T-SQL로 설정하려면 아래와 같이 코딩한다.

    1. -- unnamed
    2. CREATE TABLE #CKTable
    3. (
    4.     -- ...
    5.     Number INT NOT NULL
    6.     CHECK (Number >= 1 AND Number <= 10)
    7. )
    8.  
    9. -- named
    10. CREATE TABLE #CKTable
    11. (
    12.     -- ...
    13.     Number INT NOT NULL
    14.     CONSTRAINT CK_VALUE CHECK (Number >= 1 AND Number <= 10)
    15. )


    6. DEFAULT 정의

    DEFAULT는 값을 입력하지 않았을 때, 자동으로 입력되는 기본 값을 정의하는 방법이다.

    1. CREATE TABLE #DefaultTable
    2. (
    3.     BirthYear INT NOT NULL   DEFAULT YEAR(GETDATE()),
    4.     Addr NCHAR(2) NOT NULL   DEFAULT N'서울',
    5.     Height SMALLINT NOT NULL DEFAULT 172,
    6.     -- ...
    7. )

    위 예제와 같이 DEFAULT 키워드를 사용하고, 각 컬럼의 데이터 형식에 맞는 기본값을 지정해 주면 된다.


    7. 다음 문서

    이 문서에서 T-SQL을 이용한 제약조건 설정은 모두 테이블을 생성할 때로 한정되어 설명되어 있다.

    DB를 운영하다 보면, 이미 만들어진 테이블에 제약조건을 추가하거나, 삭제 또는 변경해야 할 일도 다반사이다.
    특히 이미 데이터가 들어가 있는 테이블이라면 말이다.


    'SQL > MS-SQL' 카테고리의 다른 글

    PIVOT/ UNPIVOT  (0) 2017.09.21
    제약 조건(Constraint) #2 (기존 테이블에 추가/삭제)  (0) 2017.09.20
    테이블변수  (0) 2017.09.20
    테이블 컬럼변경  (0) 2017.09.20
    SELF JOIN  (0) 2017.09.19

    SQL 쿼리 튜닝 팁

    1. SELECT * ... 문장은 피하세요. 

    쿼리의 결과로 모든 필드의 결과가 필요한 경우가 아니라면 SELECT리스트에 필요 한 필드들을 일일이 적어 주어야 합니다. 즉, "SELECT * From Table" 과 같은 쿼 리는 "SELECT Field1, Field2 From Table ..."과 같이 필요한 필드를 밝힌 쿼리로 작성하기 바랍니다. 


    2. 알맞은 인덱스를 구성해서 쿼리가 인덱스를 타게 하세요

    (효율적으로 인덱스를 구성하고 사용한다면 쿼리의 속도를, 그리고 궁극적으로는 DB 서버의 퍼포먼스를 놀라울 정도로 향상시킬 수 있습니다.)


    3. 쿼리가 여러 번 DB서버에 들어가지 않게 하세요

    만일 웹 서버가 DB 서버에 데이터를 요청할 때 저장 프로시저를 사용하지 않고 웹 서버에서 작성한 쿼리를 DB서버에 보내는 방식이라면, 되도록 쿼리가 DB서버에 자주 들어가지 않도록 작성하기 바랍니다. ex. 루프 내에서 단순한 SELECT쿼리를 계속 부르는 실수입니다. 이러한 경우에는 필요한 데이터를 모두 SELECT해서 가져온 다음에 레코드셋을 가지고 루프 연산을 수행하는 것이 좋습니다. ex. UPDATE 쿼리를 사용할 때 종종 실수를 하는 일이 있습니다. 어떤 값을 하나 증가시키기 위해 해당 값을 일단 SELECT 해 와서 그 값을 하나 증가시킨 뒤에 데 이터를 업데이트하는 경우가 있습니다. 이런 경우에는 당연히 "UPDATE Table SET Field = Field + 1 WHERE ..."와 같 은 쿼리로 해당 값을 SELECT하지 말고 한번의 UPDATE쿼리로 처리하는 것이 좋 습니다. ex. 서브쿼리가 있다는 것을 인식하지 못하는 데서 일어나는 실수도 있습니다. (즉, SELECT쿼리를 통해서 데이터를 반환 받고 반환 받은 값을 변환한 다음, INSERT쿼리를 통해서 변환한 값을 다른 테이블에 넣는 경우가 이러한 예에 해당합 니다.)


    4. JOIN쿼리에서 사용 메모리를 줄이는 방법을 생각하세요. 

    기본적으로 JOIN (여기에서는 Inner Join)을 사용하면 ON 절에 밝힌 조건에 의해 서 데이터를 추린 다음 WHERE 절 조건을 적용합니다. 따라서 ON 절 조건에 의해 추려지는 데이터는 메모리에 설정됩니다. 이때 아예 JOIN을 피할 수 있도록 테이블을 구성할 수 있다면 그렇게 하는 것이 가 장 좋은 방법이겠지만, 그렇게 할 수 없다면 되도록 JOIN 할 때 설정되는 임시 메 모리의 크기가 작게 만들어지도록 두 테이블에서 값은 같지만 메모리는 더 작게 차 지하는 필드를 찾아 그것을 ON조건에 사용하는 것이 유리합니다. 


    5. SELECT가 많다면 NOLOCK 힌트를 줄 수도 있어요. 

    ( NOLOCK이란 DB서버 내부적으로 해당 데이터를 읽고 있음을 표시해 주는 LOCK을 설정하지 않는 것을 의미합니다.) 서비스 내용 구성상 SELECT 쿼리는 자주 일어나는데 INSERT나 UPDATE쿼리는 거의 일어나지 않는 환경이라면 "SELECT Field1 FROM Table (NOLOCK) ..."과 같이 NOLOCK 힌트를 주면 좋습 니다. 참고로 NOLOCK힌트의 단점은 NOLOCK을 쓰게 되면 변화된 데이터 내용을 반영 하지 않거나, 데이터가 변경 중이라도 데이터를 읽어 오는 현상이 일어날 수 있기 때문에 사용상의 주의가 요구됩니다. 다이내믹 타입의 레코드셋을 사용하는 것과 같이 변경된 값이 바로 반영되어야 하는 환경이 아니라면 크게 문제 되지는 않을 것 이지만요.


    6. TOP을 이용해서 필요한 만큼만 부르세요. 

    "SELECT * ..."가 불필요한 데이터까지 다 반환하는 좋지 못한 예였다면, TOP을 사용하지 않아서 필요도 없는 데이터 행(Row)까지 반환하는 것도 비슷한 맥락에서 퍼포먼스를 저하시키는 예라고 할 수 있습니다. 예를 들어 서비스의 한 웹 페이지에 게시판 목록을 보여주는 기능, 즉 어떤 자료에 대한 리스트를 10개 보여 주고 다음 페이지로 넘어가면 다음 리스트 10개를 보여 주는 페이지를 작성한다고 합시다. 그러면 처음 웹 페이지를 구성하는 데에 필요한 데이터는 10개인데도 불구하고 모든 데이터 행을 다 SELECT해 온 다음, 웹 스크 립트에서 루프를 10번 돌리면서 페이지를 꾸미는 경우를 자주 보았습니다. 이렇게 하면 리스트 페이지를 하나씩 넘어갈 때마다 전체 데이터가 반환되므로 네트워크 부하는 물론이고 웹 서버와 DB 서버의 메모리 부하도 커지게 되므로 결코 좋은 방 법이라고 할 수 없습니다. 이런 경우에는 "SELECT TOP n ..."과 같이 TOP을 써서 필요한 수만큼 데이터를 반환하도록 해 줍니다. 


    7. 빠른 데이터 개수 반환 팁을 쓰세요. 

    테이블에 저장되어 있는 데이터의 총 개수를 알아내기 위해서 "SELECT COUNT (PromaryKeyField) ..." 혹은 "SELECT COUNT(*) ..."와 같이 COUNT함수를 사용하는 경우가 있습니다. 이것이 잘못되 었다는 말이 아니고 만일 테이블에 있는 데이터 행의 총 개수를 알아내고자 하는 경 우라면 "SELECT rows FROM sysindexes WHERE id = OBJECT_ID('Table이름') AND indid <2" 의 쿼리를 사용하는 편이 속도가 훨씬 빠르다는 것입니다. (총 개수를 구하고자 할 때 사용하며, 일부 개수를 구할 수는 없습니다.)


    8. 뷰나 스토어드 프로시져를 사용하세요. 

    긴 쿼리문을 네트웍으로 전송하는것에 비해 뷰나 스토어드 프로시져는 그 이름만 전송하기 때문에(파라미터가 있다면 이것도 포함) 네트웍 트래픽을 감소시킬 수 있 습니다.. 게다가 보안관리까지 할 수 있기 때문에 여러분이 사용자에게 숨겨야하는 컬럼의 액세스 제한을 할 수 있습니다. 


    9. 가능한 한 SQL Server 커서의 사용을 피하세요. 

    SQL Server 커서는 select문에 비해 성능상에 좋지 않습니다.. 행 단위의 처리가 필요하다면 상관질의나 유도된 테이블을 사용하도록 노력해보세요. 


    10. 트리거 대신에 제약조건을 사용하세요. 

    제약조건은 트리거보다 성능면에서 훨씬 효율적입니다. 따라서 가능한 한 제약조건 을 사용하세요. 


    11. 임시테이블 대신 테이블 변수를 사용하세요. 

    테이블 변수는 임시테이블에 비해 잠금과 로깅 작업에 적은 리소스가 소모됩니다.. 따라서 가능한 한 테이블 변수를 사용하세요.


    12. HAVING절의 사용은 피하세요. 

    Having절은 GROUP BY에 의한 결과를 제한할 때 사용합니다.. GROUP BY에 Having절을 사용하였을 경우 GROUP BY에 의해서 결과들을 모두 집계한 다음 Having절에 명시한 조건으로 맞지 않는 결과를 버리게 됩니다.. 대부분의 경우 Having절의 필요 없이 GROUP BY와 Where절만으로 원하는 결과를 얻을 수 있습 니다.. 


    13. 가능한 한 DISTINCT 문의 사용을 피하세요. 

    DISTINCT문을 사용할 경우 소트에 따른 성능 하락이 있기 때문에 꼭 필요한 경우 에만 사용하세요. 


    14. 결과에 적용된 행의 갯수를 표시하지 않아도 된다면 프로시져에 SET NOCOUNT ON을 추가해보세요. 

    몇개의 행이 적용되었는지가 전달되지 않기 때문에 네트웍 트래픽이 감소합니다. 


    15. 가능한 한 UNION 대신에 UNION ALL을 사용하세요. 

    UNION ALL이 UNION보다 훨씬 빠릅니다.. 왜냐하면 UNION ALL은 로우의 중복 검사를 하지않는 반면에 UNION은 중복행이 있건 없건간에 중복검사를 수행하기 때문입니다.


    16. SELECT * FROM TBL WHERE IDX LIKE '%A%'를하면 인덱스가 깨집니다.

    17. INNER JOIN과 LEFT OUTER JOIN의 성능이 비슷하다고 생각될경우 INNER JOIN이 성능이 더 우수합니다.


    출처: https://www.slideshare.net/ETRIBE_STG/sql-37344670

    'SQL > SQL 튜닝' 카테고리의 다른 글

    클러스터인덱스와 넌클러스터인덱스  (0) 2017.10.24
    Nested Loop, Sort Merge, Hash JOIN  (0) 2017.10.23
    옵티마이저 이해하기 - 1  (0) 2017.10.23
    INDEX 튜닝  (0) 2017.10.23
    쿼리실행순서  (0) 2017.09.01

    Table변수

    Table변수는 Meory상에 일시적으로 생성되는 Table로 Query가 실행되는 Session안에서만 유효하며 일반 변수와 같습니다. 또한 Table변수는 Primary Key, Null, Check 이 세가지 제약조건만 허락하며 Table변수선언시 사용자 데이터형식은 사용할 수 없습니다.

    주의하실 점은 Table변수를 사용하려면 먼저 생성되어 있어야 한다는 것입니다.


    1
    2
    3
    4
    5
    Declare @Temp2 Table(
     ScrapReasonID Smallint,
     Name   nVarchar(50),
     ModifiedDate DateTime
    )
    cs

    따라서 다음과 같이 임시Table을 사용할때 처럼 Table변수를 생성하는건 불가능합니다.

    1
    2
    3
    Select *
    Into @Temp2
    From Production.ScrapReason
    cs


    Table변수는 반드시 미리 생성되어 있어야 합니다.

    위 예제Query를 보시면 Create Table대신에 Declare가 사용되었습니다. Table 변수는 말그대로 변수이기 때문에 변수를 선언할때와 마찬가지로 Declare가 사용되는 것입니다.
    또한 Table변수는 Table이름의 맨앞에 @문자가 선행되어야 합니다.

    1
    2
    3
    Insert Into @Temp2
    Select *
    From Production.ScrapReason
    cs


    위에서 생성한 Table변수에 Production.ScrapReason Table의 내용을 담습니다.

    1
    Select * From @Temp2
    cs

    Table변수을 조회합니다.


    위와 같이 Table변수의 생성, 저장, 조회하는 일련의 작업과정은 Query가 실행되는 Session안에서 한단위로 이루어 져야 합니다. 예를 들어 Table변수을 생성하는 부분과 Table변수에 데이터를 저장하는 부분을 별도의 Session안에서 실행하려고 하면 오류를 일으키게 되는 것입니다.

    참고:

    보통의 경우 성능향상을 위해서는 임시Table보다는 Table변수가 더 유리합니다. 또한 SQL Server에 Disk관련 I/O가 많아 성능상에 Issue가 발생했을 경우 Table변수를 활용하면 이 문제를 어느정도 해소할 수 있습니다. 단 Table변수는 Memory상에 배치되고 실행되는 것이므로 Memory자원을 더 많이 잡아먹는 단점이 있습니다.


    따라서 분명 임시Table이나 변수Table은 용도에 따라 각각의 이점이 있을 것입니다. 따라서 맹목적으로 Table변수를 고집할 필요는 없습니다. 난해한 표현이지만 상황에 맞게 가장 적절한 대안을 찾으시길 바랍니다.


    출처: http://lab.cliel.com/entry/SQL-임시-Table과-변수-Table [CLIEL LAB]

    'SQL > MS-SQL' 카테고리의 다른 글

    제약 조건(Constraint) #2 (기존 테이블에 추가/삭제)  (0) 2017.09.20
    제약 조건(Constraint) #1 (의미와 설정)  (0) 2017.09.20
    테이블 컬럼변경  (0) 2017.09.20
    SELF JOIN  (0) 2017.09.19
    join Diagram  (0) 2017.09.19

    컬럼의 추가

    ALTER TABLE 테이블명 ADD 추가할컬럼명 데이터형(데이터크기) 컬럼속성 


    ALTER TABLE [TABLE명] ADD [컬럼명] CHAR(1) NOT NULL DEFAULT 'N'

    ALTER TABLE [TABLE명] ADD [컬럼명] CHAR(1) NULL

    컬럼변경

    ALTER TABLE [TABLE명] ALTER COLUMN [컬럼명] [컬럼자료형] NULL(NOT NULL)

    칼럼 삭제 

    ALTER TABLE [TABLE명] DROP COLUMN [컬럼명]

    기본키 추가 삭제

    ALTER TABLE [TABLE명] DROP PRIMARY KEY;   -- 기본키를 지워준다.

    ALTER TABLE [TABLE명] ADD CONSTRAINT [PK명] PRIMARY KEY ([KEY1],[KEY2],[...]);   -- PK를 생성한다.


    'SQL > MS-SQL' 카테고리의 다른 글

    제약 조건(Constraint) #1 (의미와 설정)  (0) 2017.09.20
    테이블변수  (0) 2017.09.20
    SELF JOIN  (0) 2017.09.19
    join Diagram  (0) 2017.09.19
    LEFT OUTER JOIN / WHERE  (0) 2017.09.19

    SELF JOIN

    자기 자신과 JOIN하는 것을 말한다. 예를들어 테이블에는 직속상관, 직속부서 코드만 존재한다고 할때, 직속상관, 직속부서에 대한 정보를 알고싶을때 사용한다. 그리고 누적합을 구할때에도 쓰인다.

     

    1
    2
    3
    4
    SELECT *
      FROM TABLE T1
      LEFT OUTER JOIN TABLE T2 ON T1.PK = T2.PK 
                              AND T1.컬럼 = T2.현재부서컬럼
    cs


    여기서 T1이 가준테이블(자식테이블) T2가 부모테이블이 된다.
    기준테이블에 부모테이블 컬럼이 추가되어 옆으로 붙는다고 생각하면 된다.

    생각하는 관점을 기준테이블에서 생각해야한다.

    누적합

    예를들어서 일별로 값을 가지고있는 테이블이 있다고 가정하자



    이 테이블을 월단위로 누적합을 구하고, 소계를 구하고, 테이블 전체의 총계를 구해보자.


    우선 셀프조인을 사용하여 자신보다 큰 DATE를 가진 행을 JOIN시킨다. (여기서 주의할점은 자기보다 큰 행이면서 월이 같은 행이여야한다.) 


    그리고 나중에 정렬을 위해서 SORT 컬럼을 만들어주면 

    이렇게 하면 누적합을 구한 첫번째 행들이 만들어진다.

    그리고 총계를 구하고 SORT를 걸면

    다음과 같다.


    코드






    'SQL > MS-SQL' 카테고리의 다른 글

    테이블변수  (0) 2017.09.20
    테이블 컬럼변경  (0) 2017.09.20
    join Diagram  (0) 2017.09.19
    LEFT OUTER JOIN / WHERE  (0) 2017.09.19
    NULL 비교하기  (0) 2017.09.19

    + Recent posts