ทำไมถึงมีประเภทข้อมูล varchar อยู่?

ฐานข้อมูลของฉันหลายแห่งมีเขตข้อมูลที่กำหนดเป็น varchars นี่ไม่ได้เป็นปัญหามากนักตั้งแต่ฉันอาศัยและทำงานในอเมริกา (ภาษาเดียวที่มีอยู่คือ "อเมริกัน" อะแฮ่ม )

หลังจากทำงานกับฐานข้อมูลประมาณ 5 ปีฉันก็พบว่าในที่สุดฉันก็พบปัญหาเกี่ยวกับลักษณะที่ จำกัด ของเขตข้อมูล varchar และฉันต้องแก้ไขเขตข้อมูลของฉันเพื่อเก็บข้อมูลเป็น nvarchars หลังจากต้องทำการอัปเดตอีกครั้งในตารางการแปลงเขตข้อมูล varchar เป็น nvarchar ฉันเพิ่งคิดว่า - ทำไมเรายังคงทำเช่นนี้อยู่ ฉันตัดสินใจที่จะกำหนดเขตข้อมูลใหม่ทั้งหมดของฉันเป็น nvarchar แทน varchar ซึ่งเป็นสิ่งที่ฉันเรียนรู้ที่จะทำจากหนังสือเรียนเมื่อตอนที่ฉันอยู่โรงเรียนเมื่อ 10 ปีที่แล้ว

ในปี 2554 และมี SQL Server รุ่นใหม่เมื่อปีที่แล้ว ทำไมเรายังคงสนับสนุนประเภทข้อมูล varchar เมื่อเราสามารถ / ควรใช้ nvarchar แทน?

ฉันรู้ว่ามันมักจะเป็นที่ถกเถียงกันอยู่ว่า nvarchars เป็น "ใหญ่เป็นสองเท่า" เป็น varchars ดังนั้นการใช้พื้นที่เก็บข้อมูลอาจเป็นหนึ่งในการโต้แย้งสำหรับ maitaining varcars

อย่างไรก็ตามผู้ใช้ในปัจจุบันสามารถกำหนด nvarchars เพื่อจัดเก็บข้อมูลเป็น UTF-8 แทนค่าเริ่มต้น UTF-16 หากต้องการประหยัดพื้นที่จัดเก็บ สิ่งนี้จะช่วยให้การเข้ารหัส 8 บิตหากเป็นที่ต้องการเป็นหลักในขณะที่ให้ความมั่นใจว่าอักขระที่หายากขนาด 2-8 ไบต์ที่แทรกเข้าไปในฐานข้อมูลจะไม่ทำลายอะไรเลย

ฉันพลาดอะไรไปรึเปล่า? มีเหตุผลที่ดีหรือไม่ที่สิ่งนี้ไม่ได้เปลี่ยนแปลงในช่วง 15-20 ปีที่ผ่านมา?

1. งาน varchar ดีพอสำหรับภาษายุโรปตะวันตกมากมาย (นอร์เวย์, เดนมาร์ก, เยอรมัน, ฝรั่งเศส, ดัตช์และอื่น ๆ ) ภายใต้ปัญหาการเปรียบเทียบ

2. ดูสิ่งนี้เกี่ยวกับประสิทธิภาพของ SO varchar vs nvarchar nvarchar มีความเกี่ยวข้องกับประสิทธิภาพที่ร้ายแรง

3. นี่เป็นเรื่องเล็กน้อยเมื่อเทียบกับการจัดการกับวันที่ MDY กับ DMY

นอกจากคำตอบที่อยู่มาตรฐานและความเข้ากันได้หนึ่งควรเก็บไว้ในใจประสิทธิภาพ ในขณะที่พื้นที่ดิสก์ได้รับการยอมรับอย่างง่ายดายในราคาถูก DBAs / นักพัฒนามักจะไม่สนใจข้อเท็จจริงที่ว่าประสิทธิภาพของแบบสอบถามนั้นเกี่ยวข้องโดยตรงกับขนาดแถว / หน้าของตาราง การใช้NVARCHARแทนVARCHAR(เมื่อไม่จำเป็น) จะทำให้ขนาดของแถวเป็นสองเท่าสำหรับฟิลด์อักขระของคุณ ถ้าคุณพูดว่าเขตข้อมูลที่มีความยาว 5 หรือ 10 50 ตัวคุณกำลังพูดถึงว่าอาจเพิ่มอีก 500 ไบต์ต่อแถว หากคุณมีตารางที่กว้างสิ่งนี้อาจผลักแต่ละแถวออกเป็นหลาย ๆ หน้าและมีผลเสียต่อประสิทธิภาพการทำงาน

องค์กรจำนวนมากยังคงมีแอพพลิเคชั่นฐานติดตั้งแพลตฟอร์มและเครื่องมือขนาดใหญ่ที่ติดตั้งอักขระไบต์เดียว ฐานข้อมูลไม่ค่อยอยู่แยกกัน - เป็นส่วนหนึ่งของระบบนิเวศไอที หากคุณมีองค์ประกอบหลายพันรายการและล้านบรรทัดของรหัสขึ้นอยู่กับอักขระไบต์เดียวดังนั้นคุณต้องมีเหตุผลที่ดีในการลงทุนเวลาและเงินที่ต้องใช้เพื่อเปลี่ยนเป็น Unicode การเปลี่ยนแปลงในระดับนั้นอาจใช้เวลาหลายปีกว่าจะเสร็จสมบูรณ์ ในบางสถานที่ Unicode ยังค่อนข้างใหม่หายากหรือไม่รองรับอย่างเต็มที่

VARCHAR และ NVARCHAR เป็นส่วนหนึ่งของ ISO Standard SQL การลบหรือลดค่าการสนับสนุน VARCHAR ใน SQL Server จะเป็นขั้นตอนย้อนหลังในความเข้ากันได้และการพกพา

อีกทางเลือกหนึ่งผู้ใช้วันนี้สามารถกำหนด nvarchars เพื่อเก็บข้อมูลเป็น UTF-8 แทนค่าเริ่มต้น UTF-16 หากพวกเขาต้องการประหยัดพื้นที่จัดเก็บ

VARCHARตรงนี้เป็นสิ่งที่ดีที่สุดฐานข้อมูลโอเพ่นซอร์สทำอย่างไรกับ

• MySQLจัดเตรียมutf8และucs2"การเรียง"
• SQLiteให้คุณเลือกระหว่าง UTF-8 (ค่าเริ่มต้น) และ UTF-16
• PostgreSQLรองรับ UTF-8 (แต่ไม่ใช่ UTF-16)

ไม่จำเป็นต้องมีสตริงสองชนิดแยกกัน

Microsoft เป็นสิ่งที่แปลกมากโดยมีความเห็นว่าสตริง 8 บิตใช้สำหรับการเข้ารหัสแบบดั้งเดิมและ Unicode = UTF-16 ซึ่งน่าจะเกี่ยวข้องกับ Windows API เองก็คือการรักษาcharและwchar_tวิธีนั้น

เพราะพวกเราบางคนสร้างแอพพลิเคชั่นที่มีน้ำหนักเบาขนาดเล็กลงบนฮาร์ดแวร์ที่ล้ำสมัยซึ่งไม่จำเป็นต้องใช้ความสามารถของ Unicode บางทีเราอาจจำเป็นต้องเปลี่ยนในภายหลัง แต่สำหรับตอนนี้เราไม่ต้องการมัน ฉันชอบที่สายของฉันใช้ 1/2 พื้นที่ที่พวกเขาจะต้องอยู่ภายใต้ NVARCHAR