곰탱이의 개인블로그

안녕하세요? 쓸만한게 없네 입니다.

어차피 웹에서는 자바스크립트를 통해 ASP / ASP.NET에서 유효성 체크를 하겠지만,

SQL에서 체크하는 로직은 별로 없었던 것 같네요.

CREATE FUNCTION [dbo].UFN_ValidEmailCheck

(

       @EMail VARCHAR(255)

)

RETURNS BIT

AS

BEGIN

       DECLARE @IsValid BIT

       SET @IsValid = 0    

       IF @EMail IS NOT NULL

       BEGIN

             SET @EMail = LOWER(@EMail)

             IF @EMail like '[a-z,0-9,_,-]%@[a-z,0-9,_,-]%.[a-z][a-z]%'

                    AND @EMail NOT like '%@%@%'

                    AND CHARINDEX('.@',@EMail) = 0

                    AND CHARINDEX('..',@EMail) = 0

                    AND CHARINDEX(',',@EMail) = 0

                    AND RIGHT(@EMail,1) between 'a' AND 'z'

             BEGIN

                    SET @IsValid = 1

             END

       END

       RETURN @IsValid

END

SELECT dbo.UFN_ValidEmailCheck('windtrap@paran.com') AS ValidEmail

SELECT dbo.UFN_ValidEmailCheck('박규리@naver.com') AS ValidEmail

* Result *

ValidEmail

----------

1

(1개 행이 영향을 받음)

ValidEmail

----------

0

(1개 행이 영향을 받음)

요렇게 나옵니다.

http://www.sqler.com/334903

이전에 올린 자료에 더해서 7.0과 2000 자료 찾아서 올립니다.

한 눈에 비교해 보세요.

위 자료는 김대우님께서 올려주신 자료를 바탕으로 조금 짜집기했습니다.

원문출처 : http://www.sqler.com/bSQL2000Lec/126621

그런데, 아무리 찾아봐도 제 능력으로는 일부 빠진 항목들을 채우지 못했네요. 아시는 분 있으시면 리플로. ^^.

이전에 올려드렸던2005와 2008 자료도 한번 더 올려 드립니다. ^^

봐야 할 게 많네요…

Repeatable Read 관련 설명입니다.

큰 이미지 파일은 첨부파일을 참조하세요. ^^.

1. Session 1.

  - 테이블을 생성합니다.

2. Session 1.

  - 데이터를 넣습니다. 이 때 10, 30, 50 으로 넣습니다.

3. Session 1.

  - Transaction을  REPEATABLE READ 로 걸고 10에서 50 범위를 SELECT 합니다.

  - 당연히 10, 30, 50 값만 나옵니다.

4. Session 2.

  - 테이블에 20, 40 값을 넣습니다. 데이터는 정상적으로 들어갑니다.

5. Session 2.

  - 20과 40 값을 지웁니다. 정상적으로 삭제됩니다.

6. Session 2.

  - Session2에서 30 의 값을 변경하려고 하면 Transaction 으로 인해 변경되지 않고 계속 대기하게 됩니다.

7. Session 1.

  - Rollback 하여 Session 1의 REPEATABLE READ 를 해제합니다.

  - INSERT가 아닌 SELECT기 때문에, 테이블에는 10, 30, 50이 남은 상태로 존재합니다.(20, 40 은 이미 삭제된 상태)

8. Session 1.

  - 3. 과 같이 SELECT 합니다.

9. Session 2.

  - 4. 와 같이 데이터 20, 40 을 넣습니다. 정상적으로 삽입됩니다.

10. Session 1.

  - 같은 트랜잭션 내에서 다시 한 번 SELECT 합니다.

  - 이렇게 되면 기존에 읽은 값 뿐만 아니라 Session 2.에서 입력한 20과 40도 표시되어 Pantom Read 가 됩니다.

11. Session 2.

  - 5. 와 같이 20과 40 값을 삭제하려고 하면, 10.에서 SELECT 한 Transaction의 영향으로 DELETE 가 되지 않습니다.

  - 6. 과 같이 30의 값을 변경하려고 해도 당연히 안됩니다.

어제 1 Page PPT에서 설명했던 내용을 간단하게 적어 보았습니다.

단... 배경그림은 집중도를 떨어뜨릴 것 같아서 뺐습니다. ㅋ.

일전에 모임 했을 때 Collation 이야기가 나왔었는데요.

이에 대해 간단히 이야기해 볼까 합니다.

당연히… Collation을 아시는 분들이 많을 텐데요.

Collation을 그대로 번역하면 “책 페이지 순서”입니다.

우리나라 한글로 하면 “가나다”순 인데요.

이것을 각 나라 언어를 어떤 기준으로 정렬할 지 나타낸 것이라고 보면 되겠군요.

한글용어로는 “데이터 정렬”이라는 용어를 사용합니다.

SELECT SERVERPROPERTY(N'Collation')

명령으로 현재 기본 Collation을 확인할 수 있습니다. 

물론 DB마다, Table마다 다른 정렬을 사용할 수 있습니다.

보통 Latin1_General_ CI_AS_KI_WI 이런 식으로 되어 있는데요.

이것을 나눠서 살펴 보도록 하겠습니다.

1.     Latin1_General : 언어구성을 말합니다. 각 나라의 언어를 영문으로 표기하는 부분입니다.

-  한글은 Korean_Wansung (한글 완성형, 흠… 완성형/조합형 에 대한 설명은 패스~)

-  중국어는 Chinese_PRC

보통 이런 식입니다.

2.     CI : 대/소문자 구분 부분을 말합니다.

-  CI : Case Insensitive - 대/소문자를 구분하지 않음을 말합니다.

-  CS : Case Sensitive – 대/소문자를 구분합니다.

대문자와 소문자가 구분되어 있는 나라가 아니면 CI 를 사용한다고 보시면 됩니다.

즉, 영어의 A와 a 를 같은 것으로 볼 것인지 결정하는 것이죠.

CI일 경우 A와 a를 같게 인식합니다.

-- 혹자는 MSSQL이 대소문자 구분을 하지 않아 이상한 DB라는 분이 계시는데,

   이건 MSSQL 특성을 전혀 모르고 하는 이야기이죠. -_- 설정값을 바꾸면 되는데 말이죠.

3.     AS : 악센트(성조)에 대한 구분입니다.

-  AI : Accent Insensitive – 악센트를 구분하지 않습니다.

-  AS : Accent Sensitive – 악센트를 구분합니다.

이것을 구분할 경우 'a'와 'ấ'는 서로 다르게 인식합니다. 

중국어에도 성조가 있듯, 언어의 높낮이를 구분할 경우 AI가 아닌 AS를 사용합니다.

4.     KI : 일본어 가나 구분입니다.

-  KI : Kana Insensitive – 가나를 구분하지 않습니다.

-  KS : Kana Sensitive – 가나를 구분합니다.

새삼 일본의 위력(?)을 느끼게 하네요. 가나구분이라니요.

가나란 영어/라틴의 대/소문자 구분과 비슷한 히라가나와 가타가나를 구분함을 의미합니다.

あいうえお 와 アイウエオ를 각각 다른단어로 인식할 지 여부를 결정하는 것이죠.

… 일본어의 히라가나/가타가나에 대한 상세한 설명은 패스합니다.

5.     WS : 전자/반자 구분입니다.

-  WI : Width Insensitive – 전자/반자 구분을 하지 않습니다.

-  WS : Width Sensitive – 전자/반자를 구분합니다.

전자와 반자는 같은 글자라도 2Byte를 차지하는 전자인지, 1Byte를 차지하는 반자인지 구분해 준다는 거죠.

예를 들어 보겠습니다.

DECLARE @A NVARCHAR(10)

DECLARE @B NVARCHAR(10)

SET @A = N'０1234567890'

SET @B = N'01234567890'

SELECT CASE WHEN @A = @B THEN '=' ELSE '<>' END

è  결과는 “=”으로 같다고 나옵니다.

    물론 설정하지 않을 경우 Default가 WI이기 때문입니다.

l  어느 사이트에 보면 한자의 전자와 반자, 간체 구분 등으로 설명하는데,  조금 슬프네요.-_-

MSSQL 한글버젼의 경우 기본값은 Korean_Wansung_CI_AS 입니다.

즉, “한글완성형_대/소문자구분안함_악센트구분함”인데요.

우리나라 고어의 경우엔 성조가 있었으나, 현재는 사실상 성조가 없습니다.

그럼에도 불구하고, AS가 기본값인 것은 아이러니입니다.

만약 DB마다 Collation이 다르면 서로 JOIN이 되지 않아서 일일이 JOIN 시 Collation을 지정해 줘야 하는 등 여러 가지 제약조건이 따르겠죠?

자세한 사항은 아래 내용을 참고하세요.

http://msdn.microsoft.com/ko-kr/library/ms144250.aspx

쓸 때에는 몰랐는데,  써 놓고 나니 이상한 데가 많네요. 좀 고쳤어요. -_-

안녕하세요? [쓸만한게없네] 윤선식입니다.

인덱스를 생성할 때 옵션들이 많은데요.

오늘은 이에 대해 간단하게 알아볼까 합니다.

대용량 데이터베이스를 관리할 때에는 특히 이러한 옵션들이 중요합니다.

아래 CREATE INDEX 옵션들은 2008 기준입니다. 2008 이전 버전과는 사용법의 차이가 있으니 주의하세요.

<relational_index_option> ::=

{

    PAD_INDEX = { ON | OFF }

  | FILLFACTOR = fillfactor

  | SORT_IN_TEMPDB = { ON | OFF }

  | IGNORE_DUP_KEY = { ON | OFF }

  | STATISTICS_NORECOMPUTE = { ON | OFF }

  | DROP_EXISTING = { ON | OFF }

  | ONLINE = { ON | OFF }

  | ALLOW_ROW_LOCKS = { ON | OFF }

  | ALLOW_PAGE_LOCKS = { ON | OFF }

  | MAXDOP = max_degree_of_parallelism

  | DATA_COMPRESSION = { NONE | ROW | PAGE}

     [ ON PARTITIONS ( { <partition_number_expression> | <range> }

     [ , ...n ] ) ]

}

1.     PAD_INDEX & FILLFACTOR

-       PAD_INDEX는 FILLFACTOR에서 지정한 인덱스의 채우기 비율을 사용할 것인지 여부를 결정합니다.

-       FILLFACTOR는 1과 100 사이를 사용합니다.

l  혹 어떤 분들은 FILLFACTOR를 얼마나 사용해야 하는지 물어보시는 분들이 많은데요, 이것은 분석 여부에 따라 달라질 수 있습니다. 데이터 변경이 자주 일어난다면 숫자를 낮게 주고, 그렇지 않다면 높게 주어도 될 것입니다.

l  참고로, Oracle의 PCT_FREE와는 정 반대의 개념입니다. PCT_FREE 는 얼마나 남겨둘 지를 결정하고, FILLFACTOR는 얼마나 채워둘 것인지를 결정합니다.

2.     SORT_IN_TEMPDB

-       간단히 말해서 인덱스 생성을 tempdb에서 하고 그 최종본만 실제 인덱스에 반영하는 것입니다.

-       장점은 인덱스 생성속도가 적게 걸린다는 것이고, 단점은 tempdb 가 커진다는 것입니다.

3.     IGNORE_DUP_KEY

-       UNIQUE INDEX를 생성할 때 키 중복(UNIQUE)에 대한 검사 여부를 지정합니다.

-       사실 이 기능을 ON으로 하면 UNIQUE하지 않은 행만 실패하게 되므로… 사용하시지 않는 것을 권장합니다.

4.     STATICS_NORECOMPUTE

-       통계를 다시 생성할 지 여부를 결정합니다. 기본값이 OFF인데요. 굳이 ON으로 해서 통계를 생성하지 않을 필요는 거의 없습니다.

5.     DROP_EXISTING

-       인덱스를 전체적으로 삭제하고 다시 작성할 지 여부를 결정합니다. 기본값은 OFF입니다만,  인덱스 명명 규칙이 있을 경우 이미 기존 명칭이 있을 것이므로, 삭제하고 다시 생성하기 위애 ON 으로 주어야 합니다.

6.     ONLINE

-       단순하게 바라보면, 인덱스 생성 중에 테이블을 사용할 수 있는지 여부를 지정하는 것이지만, 다시 말하자면, 인덱스를 작성하면서 TABLE LOCK을 걸지 않도록 합니다.

-       SQL 2005부터 지원되면서 DBA들에겐 큰 힘을 주었던 옵션이며 기본값이 OFF이므로 사용하려면 ON 으로 별도 지정해 주어야 합니다.

7.     ALLOW_ROW_LOCKS & ALLOW_PAGE_LOCKS

-       행이나 페이지 LOCK 여부를 결정하며 기본값이 ON입니다. 많이 사용하는 옵션은 아닙니다.

8.     MAXDOP

-       테이블의 크기가 클 경우 부하를 줄이기 위해 CPU 병렬작업을 수행할 지 결정하며 CPU 개수 64라는 값까지 줄 수 있습니다.

-       참고로 Standard Edition은 지원하지 않습니다. 엄밀히 따지면 평가판을 빼면 Enterprise Edition만 된다고 하는 편이 낫겠네요. ㅋ.

9.     DATA_COMPRESSION / ON PARTITIONS

-       DATA_COMPRESSION은 테이블을 압축하는 것과 같이 데이터 압축 여부를 선택합니다.

-       ON PARTITIONS 옵션은 DATA_COMPRESSION 옵션을 사용할 때에만 적용됩니다.

-       DATA_COMPRESSION 옵션은 NONE / ROW / PAGE 등의 옵션이 있습니다.

이상입니다. ^^.