2011-10-12 3 views
7

Tôi có nên sử dụng VARCHAR2 hoặc CHAR làm kiểu dữ liệu trong Oracle không?Kiểu dữ liệu Oracle: Tôi có nên sử dụng VARCHAR2 hoặc CHAR

Tôi đã đề xuất sử dụng CHAR cho các bảng mới này nhưng tôi quan tâm vì các bảng mới này sẽ được sử dụng để phổ biến các bảng hiện có sử dụng kiểu dữ liệu VARCHAR2. Tôi lo ngại về các khoảng trống thừa được đặt trong các trường VARCHAR2 và với các vấn đề so sánh. Tôi biết có những cách để so sánh chúng bằng cách cắt tỉa hoặc chuyển đổi chúng nhưng tôi sợ nó sẽ làm cho mã của tôi lộn xộn và lỗi.

Ý kiến ​​của bạn là gì?

+0

Err ... không gian thừa trong các trường VARCHAR2? Hoặc bạn có nghĩa là so sánh OldTable/CHAR = NewTable/VARCHAR2? –

Trả lời

8

Tôi lo ngại về khoảng trống thừa được đặt trong các trường VARCHAR2 và với các vấn đề so sánh. Tôi biết có những cách để so sánh chúng bằng cách cắt tỉa hoặc chuyển đổi chúng nhưng tôi sợ nó sẽ làm cho mã của tôi lộn xộn và lỗi.

Thực sự hoàn toàn ngược lại. Việc sử dụng CHAR sẽ buộc các chuỗi của bạn phải là độ dài cố định bằng cách đệm chúng với khoảng trống nếu chúng quá ngắn. Vì vậy, khi so sánh các CHAR với các chuỗi thông thường trong bất kỳ ứng dụng nào đang sử dụng dữ liệu, ứng dụng đó sẽ cần phải thêm cắt mỗi lần. Nói cách khác, VARCHAR2 là sự lựa chọn tự nhiên dẫn đến mã sạch hơn.

Nói chung, bạn nên luôn luôn sử dụng VARCHAR2, trừ khi bạn có lý do rất cụ thể tại sao bạn muốn cột CHAR.

Nếu bạn đang lo lắng về chuỗi có thêm dấu cách ở phía trước hoặc kết thúc, sau đó có một vài lựa chọn mà tôi suy nghĩ:

  • Hãy chắc chắn rằng bất cứ điều gì quá trình đang làm việc chèn làm một trim trên chúng trước khi chèn.
  • Thêm ràng buộc kiểm tra trên cột để đảm bảo chuỗi = trim (chuỗi).
  • Thêm trước khi chèn trình kích hoạt cấp hàng thực hiện cắt trên các chuỗi khi chúng được chèn vào.
  • Hãy chắc chắn rằng bạn làm một trim trên chuỗi bất cứ khi nào bạn truy vấn bảng
0

Tôi khuyên bạn nên tuân theo VARCHAR2.

Bạn nên sử dụng CHAR khi dữ liệu là độ dài cố định đã biết.

3

CHAR có ngữ nghĩa so sánh thú vị. Nếu bạn chỉ sử dụng VARCHAR2, thì bạn không cần phải học ngữ nghĩa CHAR. Thành thật mà nói, tôi nghĩ rằng nếu tôi có một trường có số lenth cố định đã biết, tôi vẫn định nghĩa nó là VARCHAR2 và sử dụng ràng buộc kiểm tra để thực thi độ dài cố định, thay vì học ngữ nghĩa so sánh CHAR.

Một số sẽ cho rằng CHAR có hiệu quả hơn đối với dữ liệu độ dài cố định vì không cần lưu trữ độ dài, nhưng đó là untrue on Oracle.

4

đọc:

Trích dẫn từ bài viết AskTom:

Thực tế là một CHAR/NCHAR thực sự là không có gì hơn một VARCHAR2/NVARCHAR2 trong ngụy trang làm cho tôi ý kiến ​​rằng có thực sự chỉ có hai loại chuỗi ký tự để xem xét, cụ thể là VARCHAR2 và NVARCHAR2. Tôi chưa bao giờ tìm thấy cách sử dụng cho loại CHAR trong bất kỳ ứng dụng nào. Vì một loại CHAR luôn luôn làm trống kết quả của chuỗi kết quả với chiều rộng cố định, chúng tôi phát hiện nhanh chóng rằng nó tiêu thụ lưu trữ tối đa cả trong phân đoạn bảng và bất kỳ phân đoạn chỉ mục nào. Điều đó sẽ đủ tệ, nhưng có một lý do quan trọng khác để tránh các loại CHAR/NCHAR: chúng gây nhầm lẫn trong các ứng dụng cần phải truy xuất thông tin này (nhiều người không thể "tìm" dữ liệu của mình sau khi lưu trữ ). Lý do cho điều này liên quan đến các quy tắc của chuỗi ký tự so sánh và mức độ nghiêm ngặt mà chúng được thực hiện.

+2

Xin lưu ý rằng bạn nên đăng các phần thiết yếu của câu trả lời ở đây, trên trang này, hoặc bài đăng của bạn có nguy cơ bị xóa [Xem Câu hỏi thường gặp ở đó nó đề cập đến câu trả lời 'không chỉ là một liên kết'.] (Http: // stackoverflow .com/faq # deletion) Bạn vẫn có thể bao gồm liên kết nếu bạn muốn, nhưng chỉ là một 'tham chiếu'. Câu trả lời nên tự đứng lên mà không cần liên kết. – Taryn

+0

@bluefeet done)) – gavenkoa

0

Chọn VARCHAR2(size) qua CHAR(size), vì đây là nhiều không gian và thời gian hiệu quả:

Đáng ngạc nhiên hay không, CHAR(size) cho phép chuyển nhượng các chuỗi với chiều dài ngắn hơn lensize. Trong trường hợp này, ORACLE gắn thêm size-len dấu cách vào chuỗi cho các kiểu dữ liệu CHARVARCHAR và các cửa hàng size ký tự. Kiểu dữ liệu VARCHAR2 không có đệm, chỉ len ký tự được lưu trữ.

CREATE TABLE Demo(col1 CHAR(4), col2 VARCHAR2(4)); 
INSERT INTO Demo (col1, col2) VALUES ('c', 'v'); 

Kết quả là,

col1='c ' (đệm với 3 dấu không gian, kể từ khi size của col14 và độ dài của 'c' chỉ là 1). col1='c' đánh giá FALSE, chỉ TRIM(col1)='c' đánh giá TRUE,

trong khi

col2='v' đánh giá TRUE mà không TRIM(), làm cho việc so sánh hiệu quả hơn.

Hơn nữa, so sánh giữa hai giá trị VARCHAR2 không thành công nếu độ dài của chúng khác nhau (độc lập với số size). Trong trường hợp này, không cần so sánh nhân vật. Với CHAR và cùng một size, kiểm tra độ dài luôn thất bại do đệm. Do đó, mọi ký tự phải được so sánh cho đến khi ký tự không khớp đầu tiên hoặc kết thúc chuỗi đã đạt được, tùy theo điều kiện nào xảy ra trước.

Kể từ khi cả hai CHAR(size)VARCHAR2(size) không ngăn chặn phân công của giá trị ngắn hơn size, xác định một hạn chế chiều dài nếu bạn cần phải đảm bảo rằng chỉ có giá trị với chiều dài được xác định trước (mà phải bằng size) có thể được giao.