고정길이 데이타만 들어온다면 CHAR가 좋고

가변길이 데이타라면 VARCHAR2가 좋습니다.

시롱이

http://freeboard.wawa.to

sironge@empal.com

시롱이님 답변에 예제를 드리면,

회원 아이디라면 varchar2 ,

주민번호를 사용한다면 char ( number 를 사용할수도 있겠지만),

집 주소라면 ? varchar2,

성별(남자: M, 여자 F) 인경우 char

<<결론부터 말씀드리자면 웬만하면 varchar2를 쓰시기를 권합니다>>

char를 코드성의 데이타 같이 고정길이일 때 사용하는 편입니다

한지만 요새는 DB용량이 대부분 충분한 관계로 궂이 char를

사용할 필요가 없습니다..

<< char와 varchar2를 혼용할 경우 오히려 부작용이 많습니다 >>

1)예를 들어 두개의 테이블의 pk가 char와 varchar2로 서로 type이

다를 경우 join시 match가 안되는 치명적인 문제가 발생합니다

(ex : '1234    ' 와 '1234' 는 메치가 안되겠죠 ㅡ,.ㅡ)

2)또 지적하셨듯이 검색할 때 char같은 경우 공백이 들어 가기 땜시

char의 성격을 잘 모르는 개발자 같은 경우 조회 오류를 범하기도

합니다.

3) 또한 char에  index가 결려 있는 경우 검색시 rtrim()과 같이 함수를

통해 index가 걸려 있는 칼럼에 변경/가공(suppressing)할 경우

index는 무용지물이 되어 버립니다..

그럼 .. 이만 좋은하루 되세요 ^^*

http://database.sarang.net/?inc=read&aid=20657&criteria=oracle&subcrit=&id=&limit=20&keyword=%B1%E8%C1%D6%C7%F6+varchar2&page=1

char 와 varchar2의 Table Full Scan 성능을 비교해봤습니다.

char의 경우 주지하다시피 남는 길이는 스페이스를 채워넣어서 항상 꽉 채우게 됩니다.

그러나 varchar2의 경우는 정확히 집어넣는 데이타 길이 만큼만 공간을 차지합니다.

1. 1000만건의 데이타를 집어넣은 big_table (varchar2) 와 big_table_char (char) 테이블을 만들었습니다.

2. 색인은 만들지 않고 순수하게 Table Full Scan의 성능을 Trace를 통해서 비교해봤습니다.

analyze를 돌린 후:

TABLE_NAME        PCT_FREE   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_ROW_LEN
--------------- ---------- ---------- ---------- ------------ -----------
BIG_TABLE               10   10000000     146807         1033         103
BIG_TABLE_CHAR          10   10000000     209009         3983         147

Blocks와 AVG_ROW_LEN 칼럼을 보시면 똑같은 1000만건을 수용하기 위해 VARCHAR2의 경우 훨신 작은 공간을 요구함을 알 수 있습니다.

그러니 CHAR형의 경우 공간을 더 소모하므로 Scan성능은 훨씬 더 떨어지리라는걸 알 수가 있습니다. (단위 면적당 밀집도를 비교해보건데...)

실재로 Trace 결과를 보면...

********************************************************************************

CHAR

select *
from
 big_table_char where owner = '김주현'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     2099      7.07      32.39     208216     210341          0       31457
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     2101      7.07      32.40     208216     210341          0       31457

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 61

Rows     Row Source Operation
-------  ---------------------------------------------------
  31457  TABLE ACCESS FULL BIG_TABLE_CHAR

********************************************************************************

VARCHAR2

select *
from
 big_table where owner = '김주현'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     2099      5.24      26.03     144301     148256          0       31457
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     2101      5.24      26.03     144301     148256          0       31457

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 61

Rows     Row Source Operation
-------  ---------------------------------------------------
  31457  TABLE ACCESS FULL BIG_TABLE

********************************************************************************

요약하면 32.40 < 26.03 로... varchar2의 Full Scan이 약 6초 빠름을 알 수 있습니다.

우리가 char가 더 빠르다고 생각하는건 오류라는걸 알 수 있습니다.

실재로 성능도 varchar2가 더 우세합니다.

물론 char(5)에서 5의 길이를 꽉꽉 채운다면... vachar2(5)와 성능이 동일하게 나옵니다.

Char가 가진 유일한 장점이 row Migration 현상이 없다는건데... 대부분 PCTFREE를 제대로 조정했다면 Row migration현상으로 인한 오버헤드는 심하지 않습니다.

따라서 모든 면에서 varchar2의 승리입니다.

자료형에 char를 쓰면 앞으로 방법 대상입니다. ^^; varchar2를 쓰십시오.