ความแตกต่างระหว่าง varchar และ nvarchar คืออะไร?

มันเป็นเพียงที่nvarcharรองรับอักขระหลายไบต์? หากเป็นกรณีที่มีจริงๆจุดใด ๆ นอกเหนือจากความกังวลเกี่ยวกับการจัดเก็บข้อมูลเพื่อใช้varchars?

nvarcharคอลัมน์สามารถจัดเก็บข้อมูล Unicode ใด ๆ varcharคอลัมน์ถูก จำกัด ไปยังเพจรหัส 8 บิต บางคนคิดว่าvarcharควรใช้เพราะใช้พื้นที่น้อย ฉันเชื่อว่านี่ไม่ใช่คำตอบที่ถูกต้อง ความไม่เสถียรของเพจรหัสเป็นความเจ็บปวดและ Unicode เป็นวิธีแก้ปัญหาโค้ดเพจ ด้วยราคาถูกดิสก์และหน่วยความจำทุกวันนี้ไม่มีเหตุผลที่จะเสียเวลากับหน้ารหัสอีกต่อไป

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

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

varchar : ข้อมูลอักขระที่มีความยาวไม่ผันแปรและไม่ใช่ Unicode การเปรียบเทียบฐานข้อมูลจะกำหนดหน้ารหัสที่ข้อมูลจะถูกเก็บไว้โดยใช้

nvarchar : ข้อมูลอักขระ Unicode ที่มีความยาวผันแปรได้ ขึ้นอยู่กับการเปรียบเทียบฐานข้อมูลสำหรับการเปรียบเทียบ

อาวุธที่มีความรู้นี้ใช้อย่างใดอย่างหนึ่งตรงกับข้อมูลที่คุณป้อน (ASCII v. Unicode)

ฉันมักจะใช้ nvarchar เพราะมันช่วยให้สิ่งที่ฉันกำลังสร้างสามารถทนต่อข้อมูลใด ๆ ที่ฉันโยนไปได้ ระบบ CMS ของฉันใช้ภาษาจีนโดยบังเอิญเพราะฉันใช้ nvarchar ทุกวันนี้แอปพลิเคชั่นใหม่ ๆ ไม่ควรกังวลเกี่ยวกับปริมาณเนื้อที่ที่ต้องการ

ขึ้นอยู่กับวิธีการติดตั้ง Oracle ในระหว่างกระบวนการติดตั้งตัวเลือก NLS_CHARACTERSET จะถูกตั้งค่า SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'คุณอาจจะสามารถที่จะหามันด้วยแบบสอบถาม

หาก NLS_CHARACTERSET ของคุณเป็นการเข้ารหัสแบบ Unicode เช่น UTF8 ยอดเยี่ยม การใช้ VARCHAR และ NVARCHAR นั้นเหมือนกันมาก หยุดอ่านเดี๋ยวนี้ไปเลย มิฉะนั้นหรือถ้าคุณไม่มีการควบคุมชุดอักขระของ Oracle ให้อ่านต่อ

VARCHAR - ข้อมูลถูกเก็บไว้ในการเข้ารหัส NLS_CHARACTERSET หากมีอินสแตนซ์ฐานข้อมูลอื่น ๆ บนเซิร์ฟเวอร์เดียวกันคุณอาจถูก จำกัด โดยพวกเขา และในทางกลับกันเนื่องจากคุณต้องแชร์การตั้งค่า ข้อมูลดังกล่าวสามารถจัดเก็บข้อมูลใด ๆ ที่สามารถเข้ารหัสโดยใช้ชุดตัวอักษรและไม่มีอะไรอื่น ตัวอย่างเช่นหากชุดอักขระคือ MS-1252 คุณสามารถเก็บอักขระเช่นตัวอักษรภาษาอังกฤษตัวอักษรเน้นเสียงจำนวนหนึ่งและอีกสองสามตัวอักษร (เช่น€และ -) แอปพลิเคชันของคุณจะมีประโยชน์กับสถานที่เพียงไม่กี่แห่งไม่สามารถทำงานได้ทุกที่ในโลก ด้วยเหตุนี้จึงถือเป็นแนวคิดที่ไม่ดี

NVARCHAR - ข้อมูลถูกเก็บไว้ในการเข้ารหัส Unicode รองรับทุกภาษา ความคิดที่ดี.

แล้วพื้นที่เก็บข้อมูลล่ะ VARCHAR นั้นมีประสิทธิภาพโดยทั่วไปเนื่องจากชุดอักขระ / การเข้ารหัสได้รับการออกแบบเองสำหรับสถานที่เฉพาะ เขตข้อมูล NVARCHAR เก็บไว้ในการเข้ารหัส UTF-8 หรือ UTF-16 โดยยึดตามการตั้งค่า NLS อย่างแดกดัน UTF-8 มีประสิทธิภาพมากสำหรับภาษา "ตะวันตก" ในขณะที่ยังรองรับภาษาเอเชีย UTF-16 มีประสิทธิภาพมากสำหรับภาษาเอเชียในขณะที่ยังรองรับภาษา "ตะวันตก" หากกังวลเกี่ยวกับพื้นที่เก็บข้อมูลให้เลือกการตั้งค่า NLS เพื่อให้ Oracle ใช้ UTF-8 หรือ UTF-16 ตามความเหมาะสม

แล้วความเร็วในการประมวลผลล่ะ? แพลตฟอร์มการเข้ารหัสใหม่ส่วนใหญ่ใช้ Unicode (Java, .NET, แม้แต่ c ++ std :: wstring จากปีที่แล้ว!) ดังนั้นถ้าฟิลด์ฐานข้อมูลคือ VARCHAR มันบังคับให้ Oracle แปลงระหว่างชุดอักขระในการอ่านหรือเขียนทุกครั้งซึ่งไม่ดี การใช้ NVARCHAR หลีกเลี่ยงการแปลง

บรรทัดล่างสุด: ใช้ NVARCHAR! มันหลีกเลี่ยงข้อ จำกัด และการพึ่งพาเป็นสิ่งที่ดีสำหรับพื้นที่จัดเก็บและมักจะดีที่สุดสำหรับประสิทธิภาพเช่นกัน

nvarchar เก็บข้อมูลเป็น Unicode ดังนั้นหากคุณกำลังจะจัดเก็บข้อมูลหลายภาษา (มากกว่าหนึ่งภาษา) ในคอลัมน์ข้อมูลคุณต้องมีตัวแปร N

สองเซ็นต์ของฉัน

1. ดัชนีสามารถล้มเหลวเมื่อไม่ได้ใช้ประเภทข้อมูลที่ถูกต้อง:
   ใน SQL Server: เมื่อคุณมีดัชนีอยู่เหนือคอลัมน์ VARCHAR และแสดงเป็น Unicode String, SQL Server จะไม่ใช้ดัชนี สิ่งเดียวกันนี้เกิดขึ้นเมื่อคุณแสดง BigInt ไปยังคอลัมน์ที่จัดทำดัชนีซึ่งประกอบด้วย SmallInt แม้ว่า BigInt จะเล็กพอที่จะเป็น SmallInt, SQL Server จะไม่สามารถใช้ดัชนีได้ วิธีอื่นที่อยู่รอบตัวคุณไม่มีปัญหานี้ (เมื่อระบุ SmallInt หรือ Ansi-Code ให้กับคอลัมน์ BigInt ot NVARCHAR ที่จัดทำดัชนี)

2. ประเภทข้อมูลอาจแตกต่างกันระหว่าง DBMS (ระบบการจัดการฐานข้อมูล)
   ที่แตกต่างกัน: รู้ว่าทุกฐานข้อมูลมีประเภทข้อมูลที่แตกต่างกันเล็กน้อยและ VARCHAR ไม่ได้มีความหมายเหมือนกันทุกที่ ในขณะที่ SQL Server มี VARCHAR และ NVARCHAR ฐานข้อมูล Apache / Derby มีเพียง VARCHAR และ VARCHAR นั้นอยู่ใน Unicode

ส่วนใหญ่nvarcharเก็บอักขระ Unicode และvarcharเก็บอักขระที่ไม่ใช่ Unicode

"Unicodes" หมายถึงรูปแบบการเข้ารหัสอักขระแบบ 16 บิตที่อนุญาตให้ตัวอักษรจากภาษาอื่น ๆ เช่นอารบิกฮิบรูจีนจีนญี่ปุ่นมาเข้ารหัสเป็นชุดอักขระเดียว

นั่นหมายความว่ายูนิโค้ดใช้ 2 ไบต์ต่ออักขระในการจัดเก็บและ nonunicodes ใช้เพียงหนึ่งไบต์ต่ออักขระในการจัดเก็บ ซึ่งหมายความว่ายูนิโค้ดต้องการความจุสองเท่าในการจัดเก็บเทียบกับที่ไม่ใช่ยูนิโคด

คุณถูก. nvarcharเก็บข้อมูล Unicode ในขณะที่varcharเก็บข้อมูลอักขระไบต์เดียว นอกเหนือจากความแตกต่างของพื้นที่เก็บข้อมูล ( nvarcharต้องการพื้นที่เก็บข้อมูลเป็นสองเท่าvarchar) ซึ่งคุณได้กล่าวถึงไปแล้วเหตุผลหลักสำหรับการเลือกใช้nvarcharมากกว่าvarcharนั้นก็คือความเป็นสากล (เช่นการจัดเก็บสตริงในภาษาอื่น)

ฉันจะบอกว่ามันขึ้นอยู่กับ

หากคุณพัฒนาแอปพลิเคชันเดสก์ท็อปโดยที่ระบบปฏิบัติการทำงานใน Unicode (เช่นระบบ Windows ปัจจุบันทั้งหมด) และภาษานั้นสนับสนุน Unicode (สตริงเริ่มต้นคือ Unicode เช่นใน Java หรือ C #) ให้ไปที่ nvarchar

หากคุณพัฒนาเว็บแอปพลิเคชันโดยที่สตริงมาเป็น UTF-8 และภาษาคือ PHP ซึ่งยังไม่รองรับ Unicode (ในรุ่น 5.x), varchar อาจเป็นตัวเลือกที่ดีกว่า

แม้ว่าจะจัดNVARCHARเก็บ Unicode คุณควรพิจารณาด้วยความช่วยเหลือในการเปรียบเทียบนอกจากนี้คุณยังสามารถใช้VARCHARและบันทึกข้อมูลภาษาท้องถิ่นของคุณได้

แค่คิดสถานการณ์ต่อไปนี้

การเรียงฐานข้อมูลของคุณคือภาษาเปอร์เซียและคุณบันทึกค่าเช่น 'علی' (การเขียนภาษาเปอร์เซียของ Ali) ในVARCHAR(10)ประเภทข้อมูล ไม่มีปัญหาและ DBMS ใช้เพียงสามไบต์ในการจัดเก็บ

อย่างไรก็ตามหากคุณต้องการถ่ายโอนข้อมูลของคุณไปยังฐานข้อมูลอื่นและดูผลลัพธ์ที่ถูกต้องฐานข้อมูลปลายทางของคุณจะต้องมีการเปรียบเทียบเหมือนกับเป้าหมายซึ่งเป็นภาษาเปอร์เซียในตัวอย่างนี้

หากการเปรียบเทียบเป้าหมายของคุณแตกต่างคุณจะเห็นเครื่องหมายคำถาม (?) ในฐานข้อมูลเป้าหมาย

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

ฉันเชื่อว่าการออกแบบอาจแตกต่างกัน ขึ้นอยู่กับสภาพแวดล้อมที่คุณทำงาน

ฉันได้ดูที่คำตอบและหลายคนดูเหมือนจะแนะนำให้ใช้nvarcharมากกว่าvarcharเพราะพื้นที่ไม่ได้เป็นปัญหาอีกต่อไปดังนั้นจึงไม่มีอันตรายในการทำให้ Unicode สำหรับการจัดเก็บเพิ่มเล็กน้อย สิ่งนี้ไม่เป็นความจริงเสมอไปเมื่อคุณต้องการใช้ดัชนีกับคอลัมน์ของคุณ SQL Server มีขนาด จำกัด ที่ 900 ไบต์สำหรับขนาดของเขตข้อมูลที่คุณสามารถจัดทำดัชนี ดังนั้นถ้าคุณมีvarchar(900)คุณยังสามารถดัชนี varchar(901)แต่ไม่ ด้วยจำนวนตัวอักษรที่จะลดลงครึ่งหนึ่งเพื่อให้คุณสามารถจัดทำดัชนีขึ้นไปnvarchar nvarchar(450)ดังนั้นหากคุณมั่นใจว่าคุณไม่ต้องการnvarcharฉันไม่แนะนำให้ใช้

โดยทั่วไปแล้วในฐานข้อมูลฉันแนะนำให้ใช้ขนาดที่คุณต้องการเพราะคุณสามารถขยายได้เสมอ ตัวอย่างเช่นเพื่อนร่วมงานในที่ทำงานเคยคิดว่าไม่มีอันตรายใด ๆ ในการใช้nvarchar(max)งานคอลัมน์เนื่องจากเราไม่มีปัญหากับการจัดเก็บเลย ต่อมาเมื่อเราพยายามใช้ดัชนีเหนือคอลัมน์นี้ SQL Server จะปฏิเสธสิ่งนี้ อย่างไรก็ตามหากเขาเริ่มต้นด้วยแม้varchar(5)เราจะสามารถขยายได้ในภายหลังเพื่อสิ่งที่เราต้องการโดยไม่มีปัญหาดังกล่าวซึ่งจะทำให้เราต้องวางแผนการย้ายถิ่นเพื่อแก้ไขปัญหานี้

nVarchar จะช่วยคุณจัดเก็บอักขระ Unicode เป็นวิธีที่จะไปหากคุณต้องการจัดเก็บข้อมูลที่แปลเป็นภาษาท้องถิ่น

หากมีการใช้ไบต์เดียวในการจัดเก็บอักขระจะมีการผสมกันที่เป็นไปได้ 256 แบบและด้วยเหตุนี้คุณจึงสามารถบันทึกอักขระได้ 256 ตัว การจัดเรียงเป็นรูปแบบที่กำหนดอักขระและกฎที่ใช้เปรียบเทียบและเรียงลำดับ

1252 ซึ่งเป็น Latin1 (ANSI) เป็นเรื่องธรรมดาที่สุด ชุดอักขระไบต์เดียวยังไม่เพียงพอสำหรับการจัดเก็บอักขระทั้งหมดที่ใช้โดยหลายภาษา ตัวอย่างเช่นบางภาษาในเอเชียมีอักขระหลายพันตัวดังนั้นจึงต้องใช้สองไบต์ต่ออักขระ

มาตรฐาน Unicode

เมื่อระบบที่ใช้โค้ดเพจหลายเพจถูกใช้ในเครือข่ายระบบจะจัดการการสื่อสารได้ยาก สิ่งที่เป็นมาตรฐานของ ISO และ Unicode สมาคมแนะนำUnicode Unicode ใช้สองไบต์เพื่อเก็บอักขระแต่ละตัว นั่นคือ 65,536 ตัวอักษรที่แตกต่างกันสามารถกำหนดดังนั้นตัวละครเกือบทั้งหมดสามารถครอบคลุมด้วย Unicode หากคอมพิวเตอร์สองเครื่องใช้ Unicode สัญลักษณ์ทั้งหมดจะถูกนำเสนอในลักษณะเดียวกันและไม่จำเป็นต้องมีการแปลงนี่เป็นแนวคิดเบื้องหลัง Unicode

SQL Server มีประเภทข้อมูลอักขระสองประเภท:

• ไม่ใช่ Unicode (char, varchar และข้อความ)
• Unicode (nchar, nvarchar และ ntext)

หากเราต้องการบันทึกข้อมูลตัวละครจากหลายประเทศให้ใช้ Unicode เสมอ

ผมต้องบอกว่าที่นี่ (ฉันรู้ว่าฉันอาจจะเปิดตัวเองขึ้นไปตำหนิครับ) แต่ก็เพียงครั้งเดียวเมื่อNVARCHARเป็นจริงมากขึ้นมีประโยชน์ (แจ้งให้ทราบล่วงหน้ามากขึ้นที่นั่น!) กว่าVARCHARคือเมื่อทุก collations ในทุก ของระบบที่ต้องพึ่งพาและภายในฐานข้อมูลนั้นเหมือนกัน ... ? หากไม่แล้วแปลงเปรียบเทียบมีที่จะเกิดขึ้นต่อไปและเพื่อให้ทำเช่นเดียวกับที่ทำงานได้เป็นVARCHARNVARCHAR

หากต้องการเพิ่มระบบฐานข้อมูลบางระบบเช่นSQL Server (ก่อนปี 2012)จะมีขนาดหน้าประมาณ 8K ดังนั้นหากคุณกำลังมองหาที่จัดเก็บข้อมูลที่ค้นหาได้ซึ่งไม่ได้อยู่ในรูปแบบTEXTหรือNTEXTเขตข้อมูลก็VARCHARจะให้พื้นที่ 8k เต็มในขณะที่NVARCHARให้ 4k เท่านั้น (เพิ่มเป็นสองเท่าคูณสองเท่าของพื้นที่ว่าง)

ฉันคิดว่าเพื่อสรุปการใช้อย่างใดอย่างหนึ่งขึ้นอยู่กับ:

• โครงการหรือบริบท
• โครงสร้างพื้นฐาน
• ระบบฐานข้อมูล

ทำตามความแตกต่างระหว่างโปรแกรม Sql Server VARCHAR และ NVARCHAR ชนิดข้อมูล ที่นี่คุณสามารถเห็นได้อย่างชัดเจน

โดยทั่วไปแล้ว varchar เก็บข้อมูลเป็น Unicode ดังนั้นหากคุณกำลังจะจัดเก็บข้อมูลหลายภาษา (มากกว่าหนึ่งภาษา) ในคอลัมน์ข้อมูลคุณต้องมีตัวแปร N

ความแตกต่างที่สำคัญระหว่างVarchar(n)และnvarchar(n)คือ:

Varchar(ความยาวผันแปรข้อมูลอักขระที่ไม่ใช่ Unicode) ขนาดไม่เกิน 8000 1. เป็นชนิดข้อมูลความยาวแปรผัน

2. ใช้เพื่อเก็บอักขระที่ไม่ใช่ Unicode

3. ตรงพื้นที่ 1 ไบต์สำหรับอักขระแต่ละตัว

Nvarchar: ข้อมูลอักขระ Unicode ความยาวผันแปรได้

1. เป็นประเภทข้อมูลที่มีความยาวผันแปรได้

2. ใช้เพื่อจัดเก็บอักขระ Unicode

3. ข้อมูลถูกเก็บไว้ในการเข้ารหัส Unicode รองรับทุกภาษา (ตัวอย่างเช่นภาษาอาหรับ, เยอรมัน, ฮินดี, ฯลฯ )

Jeffrey L Whitledge ที่มีคะแนนชื่อเสียงประมาณ 47,000 คะแนนแนะนำให้ใช้ nvarchar

โซโลมอน Rutzky ด้วยคะแนนชื่อเสียง ~ 33200 แนะนำ: อย่าใช้ NVARCHAR เสมอ นั่นเป็นทัศนคติที่อันตรายและมักมีค่าใช้จ่ายสูง

อะไรคือความแตกต่างของประสิทธิภาพหลักระหว่างชนิดข้อมูล varchar และ nvarchar SQL Server?

https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4

ทั้งสองคนที่มีชื่อเสียงสูงนักพัฒนาฐานข้อมูลเซิร์ฟเวอร์ sql การเรียนรู้เลือกอะไร?

มีคำเตือนมากมายในคำตอบและความคิดเห็นเกี่ยวกับปัญหาด้านประสิทธิภาพหากคุณไม่สอดคล้องกับตัวเลือก

มีความคิดเห็น pro / con nvarchar เพื่อประสิทธิภาพ

มีข้อคิดเห็น pro / con varchar สำหรับประสิทธิภาพ

ฉันมีข้อกำหนดเฉพาะสำหรับตารางที่มีหลายร้อยคอลัมน์ซึ่งในตัวมันเองอาจผิดปกติ?

ฉันเลือก varchar เพื่อหลีกเลี่ยงการเข้าใกล้ขีด จำกัด ขนาดบันทึกตาราง 8060 ของ SQL * server 2012

การใช้ nvarchar สำหรับฉันเกินขีด จำกัด 8060 ไบต์นี้

ฉันยังคิดว่าฉันควรจับคู่ประเภทข้อมูลของตารางรหัสที่เกี่ยวข้องกับประเภทข้อมูลของตารางกลางหลัก

ฉันเคยเห็นการใช้งานคอลัมน์ varchar ที่สถานที่ทำงานนี้รัฐบาลออสเตรเลียใต้โดยนักพัฒนาฐานข้อมูลที่มีประสบการณ์ก่อนหน้านี้ซึ่งการนับจำนวนแถวของตารางจะเป็นจำนวนหลายล้านหรือมากกว่านั้น (และคอลัมน์ nvarchar น้อยมากถ้ามี) ตาราง) ดังนั้นปริมาณข้อมูลแถวที่คาดหวังอาจกลายเป็นส่วนหนึ่งของการตัดสินใจนี้

nvarcharมีความปลอดภัยในการใช้งานเมื่อเทียบกับvarcharเพื่อที่จะทำให้รหัสของเราปราศจากข้อผิดพลาด (ประเภทไม่ตรงกัน) เนื่องจากnvarcharอนุญาตให้มีอักขระแบบ Unicode เช่นกัน เมื่อเราใช้whereเงื่อนไขในการสืบค้น SQL Server และหากเราใช้=โอเปอเรเตอร์จะเกิดข้อผิดพลาดบางครั้ง เหตุผลที่เป็นไปได้สำหรับสิ่งนี้คือคอลัมน์การแมปของเราจะแตกต่างvarcharกัน หากเรากำหนดไว้ในnvarcharปัญหานี้ฉันจะไม่เกิดขึ้น เรายังคงยึดติดกับvarcharและหลีกเลี่ยงปัญหานี้เราดีขึ้นใช้คำสำคัญมากกว่าLIKE=