Oracle datatype: Should I use VARCHAR2 or CHAR
Should I use VARCHAR2 or CHAR as a datatype in Oracle?
It's been suggested to me to use CHAR for these new tables I need but I'm concerned since these new tables which will be used to populat existing tables that use a VARCHAR2 datatype. I'm concerned about extra spaces being placed in the VARCHAR2 fields and with comparison issues. I know there are ways to compare them using by trimming or converting them but I'm afraid it will make my code messy and buggy.
What are your opinions?
I'm concerned about extra spaces being placed in the VARCHAR2 fields and with comparison issues. I know there are ways to compare them using by trimming or converting them but I'm afraid it will make my code messy and buggy.
It's actually quite the opposite. Using CHAR will force your strings to be a fixed length by padding them with spaces if they're too short. So when comparing CHARs to regular strings in whatever app is using the data, that app would need to add a trim every time. In other words, VARCHAR2 is the choice that naturally leads to cleaner code.
In general you should always use VARCHAR2, unless you have a very specific reason why you want a CHAR column.
If you're worried about strings that have extra spaces in the front or end, then there's a few options that come to mind:
- Make sure whatever process is doing the inserts does a trim on them before inserting.
- Add a check constraint on the column that ensures that string = trim(string).
- Add a before insert row-level trigger that does a trim on the strings as they get inserted.
- Make sure that you do a trim on the strings whenever you query the table
Read:
Quote from AskTom article:
The fact that a CHAR/NCHAR is really nothing more than a VARCHAR2/NVARCHAR2 in disguise makes me of the opinion that there are really only two character string types to ever consider, namely VARCHAR2 and NVARCHAR2. I have never found a use for the CHAR type in any application. Since a CHAR type always blank pads the resulting string out to a fixed width, we discover rapidly that it consumes maximum storage both in the table segment and any index segments. That would be bad enough, but there is another important reason to avoid CHAR/NCHAR types: they create confusion in applications that need to retrieve this information (many cannot "find" their data after storing it). The reason for this relates to the rules of character string comparison and the strictness with which they are performed.
CHAR는 흥미로운 비교 의미론을 가지고 있습니다.VARCHAR2만 사용하면 CHAR 의미론을 배울 필요가 없습니다.솔직히, 만약 내가 알려진 고정 렌즈를 가진 필드가 있다면, 나는 여전히 그것을 VARCHAR2로 정의하고, 그것의 고정 길이를 강제하기 위해 체크 제약을 사용할 것이라고 생각합니다.
일부에서는 길이를 저장할 필요가 없기 때문에 고정 길이 데이터에 대해 CHAR가 더 효율적이라고 주장하지만 Oracle에서는 그렇지 않습니다.
저는 당신이 VARCHAR2를 고수하기를 제안합니다.
데이터가 알려진 고정 길이일 때는 CHAR를 사용해야 합니다.
선택하세요.VARCHAR2(size)위에CHAR(size), 공간과 시간의 효율성이 더 높으므로 다음과 같습니다.
도.CHAR(size)길이의 문자열을 할당할 수 있습니다.len보다 짧은size. 이 경우 ORACLE이 추가됩니다.size-len데이터 유형에 대한 문자열 공백CHAR그리고.VARCHAR를 합니다.size캐릭터. 더VARCHAR2데이터 유형은 패딩 없이만 제공됩니다.len문자가 저장됩니다.
CREATE TABLE Demo(col1 CHAR(4), col2 VARCHAR2(4));
INSERT INTO Demo (col1, col2) VALUES ('c', 'v');
결과적으로.
col1='c '(후행공간이 3개인 padded)sizecol1이다.4그리고 의 길이.'c' 1입니다 1)단.col1='c'가 FALSE, TRIM(col1)='c'TRUE를 평가합니다.
반면에.
col2='v'없이 TRUE로 평가TRIM(), 비교를 보다 효율적으로 수행할 수 있습니다.
또한 둘의 비교는VARCHAR2값의 길이가 다를 경우 빠르게 실패합니다(값과 무관함).size이 경우에는 문자별 비교가 필요하지 않습니다.와 함께CHAR동일한size, 길이 검사는 패딩으로 인해 항상 실패합니다.따라서 첫 번째 문자 불일치 또는 문자열 끝에 도달할 때까지 모든 문자를 비교해야 합니다.
둘다 이래로CHAR(size)그리고.VARCHAR2(size)다음보다 짧은 값의 할당을 방지하지 않음size, 미리 정의된 길이를 가진 값(동일해야 함)만 확인해야 하는 경우 길이 제약 조건을 정의합니다.size)를 배정할 수 있습니다.
언급URL : https://stackoverflow.com/questions/7747184/oracle-datatype-should-i-use-varchar2-or-char
'programing' 카테고리의 다른 글
| 위젯 카테고리 워드프레스, 디스플레이 수 변경 (0) | 2023.10.24 |
|---|---|
| Oracle 데이터 유형:VARCHAR2를 사용해야 합니까 아니면 CHAR를 사용해야 합니까? (0) | 2023.10.24 |
| 일반적으로 신뢰할 수 있다고 여겨지는 SHA-256 자바스크립트 구현이 있습니까? (0) | 2023.10.24 |
| SQL(MariaDB) NULL 값이 무시됩니다. (0) | 2023.10.24 |
| __m128i 변수 인쇄 (0) | 2023.10.24 |