char와 varchar의 개념자체를 모르는거 같은데.. 네이버 검색해봐요 -_-;;

제 말은 고정길이로 설정하여도 괜찮을 것 까지
모두 varchar로 설정을 해 놓아서요.
단순히 추가 확장을 고려해서 모두 varchar로 쓴다는 것인지 궁금합니다만.

예전에 논쟁이 됐던 문제 내요.
어느 감리사 분이 고정 문자를 전부 CHAR로 바꾸라고 했다고 했던 걸로 기억...
말씀하신 대로 이론적으로 문자 수를 체크 하는 로직이 VARCHAR에 있는 걸로는 압니다만, 실상 건수가 아무리 많아도 사람이 느낄 수 없는 속도라 대부분의 성능 컨설팅 업체에서도 VARCHAR를 권장합니다.
VARCHAR에 대한 성능에 대한 의구심이 있는 건 너무 지나칠 정도의 이론 중심적인 생각이라 봅니다.
여지 껏 VARCHAR를 이용해 성능이 저하 되었다거나, VARCHAR를 CHAR로 바꿔 성능이 향상 되었다는 사례는 들어보지 못 한 거 같네요.

그냥 귀찮아서 그런거 아닐까요. 오라클 같은경우 문자형 타입의 경우 디폴트 값이 byte라 한글이랑 영어랑 들어가는 단어수도 다르고, 테이블 만들어 놓고 테스트 하다가 데이터크기 제약 조건 때문에 안되면 짜증도 나고.. 왠만한 대용량이 아니면 실제 체감할 정도도 못 느끼고.
만들어야될 칼럼이 한두개가 아닌데 그냥 varchar2, date, number 말고는 잘 안쓰게 되는거 같네요

저도 초보때 글쓴이님 같은 생각 많이 하였으나. 여러 대형 프로젝트 돌아다니면서 dba와도 얘기해보고 제가 느끼기에도 그렇고 에러날 확률 및 국가별 언어 데이터 크기 고려 등만 고려해도
varchar 쓰는게 좋습니다. 데모 시현같은거 하다가 데이터 크기 때문에 에러나도 났다간 프로젝트 운명 자체가 사라지는 경우도 있기 때문에.. 운영중 에러 및 성능 향상 못느낌으로 인해
확장성 좋고 운영하기 좋은 타입으로 쓰는것이지요.

그리고 지금 고정이라고 확정하고 개발하다가도 나중에 번복되서 데이터 타입 늘어지고 하는경우는 비일비재 하기 때문에 이런점도 고려를 해야 한답니다.

그때마다 개발한거 다 뒤져서 타입 다 바꿔주고 하기엔 문제가 많거든요
대형 프로젝일수록 점점 문제가 심각해지고요 어디서 이데이터를 쓰는지 다 찾아야 하기 때문에
뭐 그런 여러 복합 이유가 있습니다.

그리고 속도는 정말 눈에 보이지도 않을 정도로 영향 안주더라구요. 쿼리 돌려보시면 될겁니다.

돈땜에 그래.
효율.
이런거지.. 어느 사이트는 char만 했다.
스토리지 추가비용 5% 추가,
동일한 값도 스페이스 길이 따라 다른 값으로 인식되.. 모든 프로그램에 처리 로직 추가 1%비용 추가
미친 쓰레기 개발자들이 죄다 trim처리해서 인덱스 안타네..
튜닝비용 과 로직 수정비용 추가 3% 추가 cpu좋은걸로 바꿨네.. 오픈해야 되니까..
그런 셈이지..
반대로 죄다 Varchr2만 쓰는 프로젝트?
Char쓰는 것보다 0.1% 느려졌네 .. 근데 비용은 20% 적네...
추가로직 필요없고 스토리지 절감되고.. 당근 읽는 속도 빨라지는것 알지?

그리고 char과 varchar2 섞어쓰는 경우?
그걸 누가 콘트롤한데?
개발자들은 varchr2와 char을 바꿔 쓸데.. 섞어쓸데..
Sql에서 어떤식으로 plan이 차이날지도 예상불가인데..

결론은 돈많고 한번 테스트 해보고 싶음 char도 써

질문이 좀 거시기 해서 편하게 적음

참 그 감리사 개또 ㅇ 이네
어디서 코볼 이십년 한 사람 데리고 왔네.

좋은 답변 감사드립니다.
결국 별반다르지 않은 속도 차이이기 때문에
변동성이 좋은 varchar를 쓴다는 이야기 이군요.

char 타입의 경우 row migration을 방지하기 위해 쓰는 사이트도 많습니다.

VC2의 경우 데이터의 길이가 변동 될 경우 row migration이 발생하거든요...

CHAR 는 고정길이 데이터
VARHCAR2 는 가변길이(고정길이포함)일경우 사용하는데

VARHCAR2 의 의미는
데이터 수정시
수정할 데이터의 크기가 클 경우
블럭을 분할하여 저장할 수 있게 허용한다는 의미입니다.

CHAR 는 데이터가 없어도 빈(NULL) 데이터를 저장시
미리 공간이 할당되기 때문에
비어있는 데이터를 UPDATE 하더라도
미리 할당된 공간 내에서 저장되기 때문에
블럭 분할이 발생하지 않습니다.


그런면에서 보면
오랜 시간이 지난
테이블의 조회성능을 생각해보면

2개의 블럭 I/O 보다
1개의 블럭 I/O 를 읽어오는걸 원하게 되는 겁니다.

사실 이런 데이터는 시간이 지나야지 알수 있는거지
수십만건의 데이터를 마이그레이션 하고나서
바로 성능비교를 한다고 해서 알 수 있는건 아닙니다.

그리고 VARHCAR2 만 사용하는 프로젝트로 많은데

이럴경우
고정길이 데이터를 저장할때 VARCHAR2 + NOT NULL 으로 설정해서
블럭분할을 방지하고 있습니다.


그리고
금액 필드에 NUBMER 를 설정하듯이
고정길이 문자열은 CHAR 로 설정하는게 맞습니다.

어느 컨설팅 업체가 VARCHAR2 를 권장하는지
그 업체명이 궁금하군요.


두번째로
편하게 이야기하는데

글도 제대로 못쓰고 철자도 틀려가면서
(혹시나 해서 varchr2 가 있는지 알아본 내가 바보스럽다.)

감리사를 개또 ㅇ 이네 뭐네 하는
개또 ㅇ 같은 넌 뭐냐?

char 을 꺼리는 이유 중 하나는, 완전한 고정길이 데이터가 아닌 이상 남는 공간에 공백문자가 들어간다는 것입니다. 고수들이면 모르는데, 초보들은 이걸 몰라서 equals 로 비교했는데 값이 다른걸 몰라서 고생하거나, trim() 을 추가로 써줘야 해서 낭비가 더 늘어나는 경우가 많기 때문입니다.
또한, DBMS 가 보통 훨씬 좋은 장비에 세팅이 되기 때문에 가급적 DBMS 에서 문자열 처리를 하고 오는게 습관이 되어서 그런 것도 있습니다.

모델러 마음

연세 많으신분들은 쓰시더라구요..

지붕뚫고높이차 님

기업의 시스템은 다음처럼 발전해 왔습니다.

메인프레임(코볼)->메인프레임(db2+코볼)->유닉스(DB2+코볼)->유닉스(ORACLE+코볼)->유닉스(ORACLE)

전자, 금융, 통신, 유통처럼 전산을 일찍 도입한 기업일수록 코볼을 처음에 경험했죠.
차세대 이후에도 배치를 코볼로 사용하는 경우가 남아 있습니다.

데이터표준화라는 개념이 차세대프로젝트에 적용이 시작된지 10년이 지나지 않았습니다.
아니 DA가 차세대프로젝트에 필수적으로 참여하기 시작한게 6년 전쯤입니다.

코볼에는 가변형이라는 데이터 타입이 존재할까요?
존재하지 않습니다.
이런 상황에서 코볼에서의 데이터 타입 따로, 오라클에서의 데이터 타입을 따로 잡고
데이터 표준화가 가능했을까요?

데이터 표준화란 하나의 뜻에 단일용어와 단일타입을 만드는게 기본입니다.
그걸 벗어나는 것을 통일하는 것을 용어 표준화라고 하죠.
차세대 수행당시에 DA전문인력도 적고, 분석설계 기간도 적은데, 이런 상황을 경험한 전문인력은 손꼽을 수 있죠.
무엇보다 이런상황에서 어떻게 하면 어떤 결과가 나올지 아무도 몰랐습니다.

조직에서 흔히 이런 경우 어떻게들 하죠?
아무도 대답하지 않으면 앞서가는 사람 따라갑니다.

1.아무도 책임지거나 나서지 않기에, 기존에 돌고 있는 코볼의 type위주로... 리스크 회피

2.논리적으로 그럴듯 하게 근거를 가지고 주장 하는 DB컨설팅 업체를 따라서... char과 varchar2를 나누는 형태로..

1번의 경우 다른 분들이 이야기한 문제들이 발생하기 시작합니다.
글자가 깨지거나, 비교가 안되서 trim으로 떡칠하고, 스페이스로 보이지만 스페이스가 아닌 ascii값으로 데이터가 오염되고
그로 인해 프로그램에서 보이지 않는 데이터까지 발생합니다.

2번의 경우도 trim 떡칠, 개발자들이 char형인지 varchar2형인지에 늘 신경을 씁니다.
다른 분들이 언급한 것 같은 현상이 발생합니다.
아직도 추세는 char+varchar2를 선호합니다.

차세대에서 설계를 경험하신 분들은 아실겁니다.

책에 나오는 서푼의 지식으로 얄팍하게 아는척하거나...
전체를 보는 시야 없이 코앞의 현상만으로 바라보거나...
달을 가르키는데 손가락을 바라보거나...
열심히 공부했으니 내가 아는 지식이 다라고 생각하거나...
얼마나 프로젝트에 악영향을 끼치는지..

대형 시스템의 프로젝트는 리소스관리가 생명이고요.

미친 쓰레기 개발자들도 지식은 있다는 것은 잘 알고 있습니다.
문제는 그런 개발자들 백명이서 뿜어되는 문제 sql이
수천개쯤 되면 프로젝트를 관리해야 하는 관점에서는
리스크 및 리소스관리가 생명입니다.
간단하게 varchar2를 표준으로 정하면 그런 문제가 싸그리 사라지는데...
뭐 때문에 관리의 복잡도를 증가시킵니까?
간단하게 기준 하나만 공표해서
수십맨먼스를 절감하고, 프로젝트를 성공시키기 위해 다른곳에 절감된
리소스를 투입하는 편이 효과적이지 않을까요?

흔히 이런 말하는 사람들 있습니다.
"힘들어도 해야지 힘들다고 안할꺼야?"
전 사안에 따라 다음과 같이도 대답합니다.
"직접 하세요. 그건 안됩니다. 아님 할 수 있는 사람 데리고 와서 맡기십쇼"
그런다고 나가라는 사람 한명도 없었습니다.

힘들어도 해야 할 것을 하는 것과 서푼의 지식으로 멍청한 짓을 하는 것은
성공과 폭탄의 차이입니다.

지붕뚫고높이차 님

dml에 의해 세그먼트가 확장되면서 블럭이 분할된다고요?
그래서 오랜 기간이 지나면 느려진다고요?
그래서 char를 쓴다고요?

흠 처음 듣는 논리군요.
"어 그럴 수도 있을까?"
순간 생각했습니다.

세그먼트가 확장되면서 블럭이 분할되어서 CHAR로 한다고 하신것은 실무적인 부분을
전혀 모르는 의견입니다.

요즘 사이트에서는 대부분 REORGNIZATION TOOL을 이용합니다.
이게 뭐냐면... 분할된 블럭을 합치고, 세그먼트의 내부를 정렬 및 정리하는 기능을 합니다.
ORACLE에서 제공해주는 기능도 있지만 대부분 타사 TOOL을 이용하죠.
아니면 메뉴얼하게 정기적으로 INDEX REBUILD 및 TABLE EXP&IMP 작업을 하기도 합니다.
방법은 여러가지죠.

중요한 것은 대부분의 BIG 사이트는 정기작업으로 수행 한다는 것입니다.
그리고 재미있는 것은 해봐야 정말 갱신이 엄청나게 많은 테이블 몇몇을
제외하고는 별로 빨라지지 않는다는 것이죠.

돌아와서
차세대사이트에서 스토리지 30% 절감하면...
연간 수억이상 절감됩니다.
정말 큰 사이트에서는 십억 단위겠죠.
연간 금액이니 10년으로 치면 수십억~백억이상이 되는 금액입니다.
거기다 운영시 용이성과 개발시 용이성을 따지면 가치는 이루 말할 수가 없습니다.


지붕뚫고높이차 님이 DB에 관심이 정말 많다면

DB쪽 변두리에서 기웃거리지 말고 용기를 가지고
들어오라고 권한고 싶습니다.

이만 귀찮아서 ...

지붕님 글 보고 로그인 했는 데 butnim 님이 먼저 설명해 주셨네요.
빈 값도 용량이고, 이게 수TB 단위의 DB에선 무시 할 수 없는 용량이 되게 마련이죠.
이게 컬럼에 대한 용량뿐 아니라 인덱스에 대한 용량도 추가 되는 것 이죠.
좀 오래된 자료 지만 인팍에서 현 B2EN 컨설팅 조광원 대표가 강연한 대용량 데이터베이스에서도 CHAR와 VARCHAR에 대한 주제에 대해서도 살짝 나옵니다.
예시로 나온 내용에도 Y/N 플래그 값의 경우 대부분의 값이 Y라면 Y일 경우를 NULL로 넣고 값이 없을 때만 N값을 넣어주는 게 테이블 사이즈도 줄고 인덱스 사이즈도 줄어든다는 내용으로 기억하네요.
로우 마이그레이션에 대한 부담은 butnim말씀 대로 주기적인 reorg를 해주는 게 낫고요.
이 내용에 대한 이론으로 두가지 다 타당성이 있긴 하지만, 저는 아무래도 장단을 따졌을 때 VARCHAR를 쓰는 게 낫다는 쪽에 한표 던지고 싶네요.

운영되고 있는 상황에서 CHAR 속성을 가진 컬럼 사이즈를 늘리면
해당 테이블 핸들링하는 소스도 다 수정해야 되더라고요 TRIM 넣어서요...

저도 varchar를 선호합니다.
제가 알고 있던 내용은 butnim이 다 써주셨네요.
varchar만 사용하면 용량도 절감되고 많은 개발자들의 수고를 많이 줄여주는데, 구태여 char를 사용할 필요가 없죠.