Tại sao vẫn có một kiểu dữ liệu varchar?

Nhiều cơ sở dữ liệu của tôi có các trường được định nghĩa là varchars. Điều này không có vấn đề gì nhiều kể từ khi tôi sống và làm việc ở Mỹ (nơi ngôn ngữ duy nhất tồn tại là "American". Ahem )

Sau khi làm việc với cơ sở dữ liệu khoảng 5 năm, cuối cùng tôi đã gặp phải vấn đề với tính chất hạn chế của trường varchar và tôi phải sửa đổi các trường của mình để lưu trữ dữ liệu dưới dạng nvarchar. Sau khi phải thực hiện một bản cập nhật khác cho một bảng, chuyển đổi một trường varchar thành một nvarchar, tôi chỉ có suy nghĩ-- tại sao chúng ta vẫn làm theo cách này? Từ lâu tôi đã đưa ra quyết định tinh thần khi xác định tất cả các trường văn bản mới của mình thành nvarchar, thay vì varchar, đó là điều tôi học được từ sách giáo khoa khi tôi còn đi học 10 năm trước.

Đó là năm 2011 và đã có một bản phát hành mới của SQL Server vào năm ngoái. Tại sao chúng ta tiếp tục hỗ trợ một kiểu dữ liệu varchar khi chúng ta có thể / nên sử dụng nvarchar?

Tôi biết rằng người ta thường lập luận rằng nvarchar "lớn gấp đôi" so với varchars, vì vậy việc sử dụng không gian lưu trữ có thể là một lý lẽ cho việc thay đổi varcars.

Tuy nhiên, người dùng ngày nay có thể định nghĩa nvarchar của họ để lưu trữ dữ liệu dưới dạng UTF-8 thay vì UTF-16 mặc định nếu họ muốn tiết kiệm dung lượng lưu trữ. Điều này sẽ cho phép mã hóa 8 bit nếu điều đó chủ yếu là mong muốn, trong khi đảm bảo rằng ký tự 2-8 byte hiếm hoi được chèn vào DB của chúng sẽ không phá vỡ bất cứ điều gì.

Tui bỏ lỡ điều gì vậy? Có một lý do chính đáng tại sao điều này đã không thay đổi trong 15-20 năm qua?

1. công việc varchar đủ tốt cho nhiều ngôn ngữ Tây Âu (tiếng Na Uy, tiếng Đan Mạch, tiếng Đức, tiếng Pháp, tiếng Hà Lan, v.v.) cũng có một số vấn đề đối chiếu

2. Xem điều này trên SO varchar vs nvarchar hiệu suất nvarchar có ý nghĩa hiệu suất nghiêm trọng

3. Điều này là không đáng kể so với việc xử lý ngày MDY vs DMY

Ngoài các câu trả lời giải quyết các tiêu chuẩn và khả năng tương thích, người ta cũng nên ghi nhớ hiệu suất. Mặc dù dung lượng ổ đĩa dễ dàng được chấp nhận là giá rẻ, các DBA / Nhà phát triển thường bỏ qua thực tế là hiệu năng truy vấn đôi khi liên quan trực tiếp đến kích thước hàng / trang của bảng. Sử dụng NVARCHARthay vì VARCHAR(khi không cần thiết) sẽ tăng gấp đôi kích thước hàng cho các trường ký tự của bạn một cách hiệu quả. Nếu bạn có, giả sử, 5 hoặc 10 trường có độ dài 50, bạn đang nói về khả năng thêm 500 byte mỗi hàng. Nếu bạn có một bảng rộng, điều này có thể đẩy mỗi hàng thành nhiều trang và có ảnh hưởng xấu đến hiệu suất.

Nhiều tổ chức vẫn có một cơ sở lớn các ứng dụng, giao diện, nền tảng và công cụ được cài đặt giả định các ký tự một byte. Cơ sở dữ liệu hiếm khi sống tách biệt - chúng là một phần của hệ sinh thái CNTT. Nếu bạn có hàng ngàn thành phần và hàng triệu dòng mã phụ thuộc vào các ký tự byte đơn thì bạn cần một lý do chính đáng để đầu tư thời gian và tiền bạc cần thiết để chuyển sang unicode. Thay đổi trên quy mô đó có thể mất nhiều năm để hoàn thành. Ở một số nơi, Unicode vẫn còn tương đối mới, hiếm hoặc không được hỗ trợ đầy đủ.

VARCHAR và NVARCHAR đều là một phần của tiêu chuẩn SQL. Xóa hoặc không hỗ trợ VARCHAR trong SQL Server sẽ là một bước lùi về tính tương thích và tính di động.

Ngoài ra, người dùng ngày nay có thể xác định nvarchar của họ để lưu trữ dữ liệu dưới dạng UTF-8 thay vì UTF-16 mặc định nếu họ muốn tiết kiệm dung lượng lưu trữ.

Đây chính xác là những gì hầu hết các cơ sở dữ liệu nguồn mở làm với VARCHAR.

• MySQL cung cấp utf8và ucs2"đối chiếu".
• SQLite cho bạn lựa chọn giữa UTF-8 (mặc định) và UTF-16.
• PostgreSQL hỗ trợ UTF-8 (nhưng không phải UTF-16).

Không cần phải có hai loại chuỗi riêng biệt.

Microsoft là một công ty kỳ quặc với quan điểm rằng các chuỗi 8 bit dành cho mã hóa kế thừa và Unicode = UTF-16. Điều này có lẽ liên quan đến chính Windows API charvà wchar_tcách đó.

Bởi vì một số người trong chúng tôi xây dựng các ứng dụng nhẹ hơn, nhỏ hơn trên phần cứng ít hơn so với các phần cứng hiện đại không có nhu cầu về khả năng Unicode. Có thể chúng ta sẽ cần thay đổi nó sau, nhưng bây giờ, chúng ta đơn giản là không cần nó. Tôi thích các chuỗi của tôi chiếm 1/2 dung lượng mà chúng sẽ phải có trong NVARCHAR.