Nếu bạn có bất cứ điều gì gần với sự lựa chọn, hãy sử dụng bộ ký tự Unicode cho toàn bộ cơ sở dữ liệu. Cuộc sống nói chung dễ dàng hơn một cách mù quáng theo cách đó.
- Có rất nhiều tiện ích và thư viện của bên thứ ba không hỗ trợ các cột NCHAR / NVARCHAR2 hoặc không làm việc với các cột NCHAR / NVARCHAR2 trở nên dễ chịu. Chẳng hạn, nó cực kỳ khó chịu khi công cụ báo cáo mới sáng bóng của bạn không thể báo cáo về dữ liệu NVARCHAR2 của bạn.
- Đối với các ứng dụng tùy chỉnh, làm việc với các cột NCHAR / NVARCHAR2 yêu cầu nhảy qua một số vòng lặp mà không làm việc với các cột được mã hóa Unicode CHAR / VARCHAR2. Ví dụ:trong mã JDBC, bạn liên tục gọi phương thức Statement.setFormOfUse. Các ngôn ngữ và khuôn khổ khác sẽ có các gotchas khác; một số sẽ được ghi lại tương đối đầy đủ và những phần nhỏ khác sẽ tương đối mù mờ.
- Nhiều gói cài sẵn sẽ chỉ chấp nhận (hoặc trả về) một VARCHAR2 thay vì một NVARCHAR2. Bạn vẫn có thể gọi họ vì chuyển đổi ngầm định nhưng bạn có thể gặp phải các vấn đề về chuyển đổi bộ ký tự.
- Nói chung, việc có thể tránh các vấn đề chuyển đổi bộ ký tự trong cơ sở dữ liệu và đưa các vấn đề đó xuống cạnh mà cơ sở dữ liệu đang thực sự gửi hoặc nhận dữ liệu từ máy khách giúp công việc phát triển ứng dụng dễ dàng hơn nhiều. Đó là đủ công việc để gỡ lỗi các vấn đề chuyển đổi bộ ký tự do truyền qua mạng - tìm ra rằng một số dữ liệu bị hỏng khi một thủ tục được lưu trữ kết hợp dữ liệu từ VARCHAR2 và NVARCHAR2 và lưu trữ kết quả trong VARCHAR2 trước khi nó được gửi qua mạng có thể kinh khủng.
Oracle đã thiết kế các kiểu dữ liệu NCHAR / NVARCHAR2 cho các trường hợp bạn đang cố gắng hỗ trợ các ứng dụng cũ không hỗ trợ Unicode trong cùng cơ sở dữ liệu với các ứng dụng mới đang sử dụng Unicode và cho các trường hợp có lợi khi lưu trữ một số dữ liệu Unicode với một cơ sở dữ liệu khác mã hóa (nghĩa là bạn có một lượng lớn dữ liệu tiếng Nhật mà bạn muốn lưu trữ bằng cách sử dụng mã hóa UTF-16 trong NVARCHAR2 hơn là mã hóa UTF-8). Nếu bạn không thuộc một trong hai trường hợp đó và có vẻ không giống như bạn, tôi sẽ tránh sử dụng NCHAR / NVARCHAR2 bằng mọi giá.
Trả lời theo dõi của bạn
Ứng dụng của chúng tôi thường ở một mình trên cơ sở dữ liệu Oracle và tự xử lý dữ liệu. Phần mềm khác kết nối với cơ sở dữ liệu được giới hạn cho nhà phát triểnToad, Tora hoặc SQL.
Ý bạn là "tự chăm sóc dữ liệu" là gì? Tôi hy vọng bạn không nói rằng bạn đã định cấu hình ứng dụng của mình để bỏ qua các quy trình chuyển đổi bộ ký tự của Oracle và rằng bạn tự mình thực hiện tất cả quá trình chuyển đổi bộ ký tự.
Tôi cũng giả định rằng bạn đang sử dụng một số loại API / thư viện để truy cập cơ sở dữ liệu ngay cả khi đó là OCI. Bạn đã xem xét những thay đổi nào bạn sẽ cần thực hiện đối với ứng dụng của mình để hỗ trợ NCHAR / NVARCHAR2 và liệu API bạn đang sử dụng có hỗ trợ NCHAR / NVARCHAR2 không? Việc bạn nhận được dữ liệu Unicode trong C ++ không thực sự cho thấy rằng bạn sẽ không cần thực hiện các thay đổi (có khả năng quan trọng) để hỗ trợ các cột NCHAR / NVARCHAR2.
Chúng tôi cũng sử dụng SQL * Loader và SQL * Plus để kết hợp với các câu lệnh cơ bản của cơ sở dữ liệu hoặc để nâng cấp giữa các phiên bản của sản phẩm. Chúng tôi chưa nghe thấy bất kỳ vấn đề cụ thể nào với tất cả các phần mềm liên quan đến NVARCHAR2.
Các ứng dụng đó đều hoạt động với NCHAR / NVARCHAR2. NCHAR / NVARCHAR2 giới thiệu một số phức tạp bổ sung vào các tập lệnh, đặc biệt nếu bạn đang cố gắng mã hóa các hằng số chuỗi không thể đại diện trong bộ ký tự cơ sở dữ liệu. Tuy nhiên, bạn chắc chắn có thể giải quyết các vấn đề.
Chúng tôi cũng không biết rằng những người quản trị cơ sở dữ liệu trong số các khách hàng của chúng tôi muốn sử dụng các công cụ khác trên cơ sở dữ liệu không thể hỗ trợ dataon NVARCHAR2 và chúng tôi không thực sự quan tâm đến việc liệu các công cụ của họ có thể bị hỏng hay không, dù sao thì họ cũng là những người có kỹ năng và có thể tìm thấy các công cụ khác nếu cần.
Mặc dù tôi chắc chắn rằng khách hàng của bạn có thể tìm thấy các cách thay thế để làm việc với dữ liệu của bạn, nhưng nếu ứng dụng của bạn không hoạt động tốt với công cụ báo cáo doanh nghiệp hoặc công cụ ETL doanh nghiệp của họ hoặc bất kỳ công cụ máy tính để bàn nào mà họ tình cờ được trải nghiệm, thì rất có thể rằng khách hàng sẽ đổ lỗi cho ứng dụng của bạn hơn là các công cụ của họ. Nó có thể không phải là một công cụ ngăn chặn chương trình, nhưng cũng chẳng có lợi gì nếu khiến khách hàng đau buồn một cách không cần thiết. Điều đó có thể không thúc đẩy họ sử dụng sản phẩm của đối thủ cạnh tranh, nhưng sẽ không khiến họ háo hức đón nhận sản phẩm của bạn.
Chúng tôi cũng có thể mong đợi sự phá vỡ hiệu suất nếu ứng dụng của chúng tôi (được biên dịch dưới Visual C ++), sử dụngwchar_t để lưu trữ UTF-16, có hiệu suất chuyển đổi mã hóa trên tất cả dữ liệu đã xử lý?
Tôi không chắc bạn đang nói về "chuyển đổi" nào. Điều này có thể quay trở lại câu hỏi ban đầu của tôi về việc liệu bạn có đang nói rằng bạn đang bỏ qua lớp NLS của Oracle để tự mình thực hiện chuyển đổi bộ ký tự hay không.
Tuy nhiên, điểm mấu chốt của tôi là tôi không thấy bất kỳ lợi ích nào khi sử dụng NCHAR / NVARCHAR2 dựa trên những gì bạn đang mô tả. Có rất nhiều mặt trái tiềm ẩn khi sử dụng chúng. Ngay cả khi bạn có thể loại bỏ 99% nhược điểm là không liên quan đến nhu cầu cụ thể của bạn, tuy nhiên, bạn vẫn phải đối mặt với tình huống mà tốt nhất đó là sự rửa sạch giữa hai cách tiếp cận. Do đó, tôi muốn sử dụng phương pháp tối đa hóa tính linh hoạt trong tương lai và đó là chuyển đổi toàn bộ cơ sở dữ liệu sang Unicode (có lẽ là AL32UTF8) và chỉ sử dụng điều đó.
