ما هو الفرق بين varchar و nvarchar؟

Question

هل هذا مجرد nvarchar يدعم أحرف متعددة البايت؟إذا كان الأمر كذلك، فهل هناك حقًا أي فائدة، بخلاف المخاوف المتعلقة بالتخزين، لاستخدامها؟ varchars?

Answer 1

ان nvarchar يمكن للعمود تخزين أي بيانات Unicode.أ varchar يقتصر العمود على مخطط الشفرة 8 بت.بعض الناس تقتعد هكذا varchar يجب استخدامه لأنه يشغل مساحة أقل.أعتقد أن هذه ليست الإجابة الصحيحة.يعد عدم توافق صفحة التعليمات البرمجية أمرًا مؤلمًا، كما أن Unicode هو الحل لمشكلات صفحة التعليمات البرمجية.مع الأقراص والذاكرة الرخيصة هذه الأيام، لم يعد هناك سبب لإضاعة الوقت في العبث بصفحات الأكواد بعد الآن.

تستخدم جميع أنظمة التشغيل ومنصات التطوير الحديثة Unicode داخليًا.باستخدام nvarchar بدلا من varchar, ، يمكنك تجنب إجراء تحويلات التشفير في كل مرة تقرأ فيها من قاعدة البيانات أو تكتب إليها.تستغرق التحويلات وقتًا، وتكون عرضة للأخطاء.والتعافي من أخطاء التحويل مشكلة غير تافهة.

إذا كنت تتعامل مع تطبيق يستخدم ASCII فقط، فأنا أوصي باستخدام Unicode في قاعدة البيانات.ستعمل خوارزميات تجميع نظام التشغيل وقاعدة البيانات بشكل أفضل مع Unicode.يتجنب Unicode مشاكل التحويل عند التعامل معه آخر أنظمة.وسوف تستعد للمستقبل.ويمكنك دائمًا التحقق من أن بياناتك مقيدة بـ 7 بت ASCII لأي نظام قديم تحتاج إلى صيانته، حتى أثناء الاستمتاع ببعض مزايا تخزين Unicode الكامل.

Answer 2

varchar:بيانات ذات أحرف متغيرة الطول وغير Unicode.يحدد ترتيب قاعدة البيانات صفحة الرموز التي يتم تخزين البيانات باستخدامها.

nvarchar:بيانات أحرف Unicode متغيرة الطول.تعتمد على ترتيب قاعدة البيانات لإجراء المقارنات.

مسلحًا بهذه المعرفة، استخدم أيًا كان يطابق بيانات الإدخال الخاصة بك (ASCII v.يونيكود).

Answer 3

أستخدم دائمًا nvarchar لأنه يسمح لأي شيء أقوم بإنشائه بمقاومة أي بيانات أقوم بإلقائها عليه.يعمل نظام CMS الخاص بي باللغة الصينية عن طريق الصدفة، لأنني استخدمت nvarchar.في هذه الأيام، لا ينبغي لأي تطبيقات جديدة أن تهتم بمقدار المساحة المطلوبة.

Answer 4

يعتمد ذلك على كيفية تثبيت 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 إلى تجنب التحويل.

الحد الأدنى:استخدم نفارتشار!إنه يتجنب القيود والتبعيات، وهو مناسب لمساحة التخزين، وعادة ما يكون الأفضل للأداء أيضًا.

Answer 5

يقوم nvarchar بتخزين البيانات بتنسيق Unicode، لذلك، إذا كنت ستقوم بتخزين بيانات متعددة اللغات (أكثر من لغة واحدة) في عمود بيانات، فأنت بحاجة إلى متغير N.

Answer 6

سنتى

1. يمكن أن تفشل الفهارس عند عدم استخدام أنواع البيانات الصحيحة:
   في خادم SQL:عندما يكون لديك فهرس فوق عمود VARCHAR وتقدمه بسلسلة Unicode، فإن 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.

Answer 7

خاصة nvarchar يخزن أحرف Unicode و varchar يخزن أحرف غير Unicode.

"Unicodes" يعني نظام ترميز أحرف 16 بت يسمح بتشفير أحرف من العديد من اللغات الأخرى مثل العربية والعبرية والصينية واليابانية في مجموعة أحرف واحدة.

وهذا يعني أن الرموز الموحدة تستخدم 2 بايت لكل حرف للتخزين بينما تستخدم الرموز غير الموحدة بايتًا واحدًا فقط لكل حرف للتخزين.مما يعني أن الرموز الموحدة تحتاج إلى سعة مضاعفة للتخزين مقارنةً بالرموز غير الموحدة.

Answer 8

أنت على حق. nvarchar يخزن بيانات Unicode أثناء varchar يخزن بيانات الأحرف أحادية البايت.بخلاف اختلافات التخزين (nvarchar يتطلب ضعف مساحة التخزين varchar)، والذي ذكرته بالفعل، هو السبب الرئيسي لتفضيلك nvarchar زيادة varchar سيكون التدويل (أيتخزين السلاسل بلغات أخرى).

Answer 9

أود أن أقول، ذلك يعتمد.

إذا قمت بتطوير تطبيق سطح مكتب، حيث يعمل نظام التشغيل في Unicode (مثل جميع أنظمة Windows الحالية) واللغة تدعم Unicode أصلاً (السلاسل الافتراضية هي Unicode، كما هو الحال في Java أو C#)، فانتقل إلى nvarchar.

إذا قمت بتطوير تطبيق ويب، حيث تأتي السلاسل بتنسيق UTF-8، واللغة هي PHP، والتي لا تزال لا تدعم Unicode أصلاً (في الإصدارات 5.x)، فمن المحتمل أن يكون varchar خيارًا أفضل.

Answer 10

سيساعدك nVarchar على تخزين أحرف Unicode.هذا هو الطريق الذي يجب اتباعه إذا كنت تريد تخزين البيانات المترجمة.

Answer 11

إذا تم استخدام بايت واحد لتخزين حرف ما، فهناك 256 مجموعة محتملة، وبالتالي يمكنك حفظ 256 حرفًا مختلفًا.الترتيب هو النمط الذي يحدد الأحرف والقواعد التي يتم من خلالها مقارنتها وفرزها.

1252، وهو اللاتينية 1 (ANSI)، هو الأكثر شيوعًا.مجموعات الأحرف أحادية البايت غير كافية أيضًا لتخزين كافة الأحرف المستخدمة بواسطة العديد من اللغات.على سبيل المثال، تحتوي بعض اللغات الآسيوية على آلاف الأحرف، لذا يجب أن تستخدم بايتين لكل حرف.

معيار يونيكود

عند استخدام الأنظمة التي تستخدم صفحات رموز متعددة في الشبكة، يصبح من الصعب إدارة الاتصال.لتوحيد الأمور، قدم اتحاد ISO وUnicode يونيكود.يستخدم Unicode وحدتي بايت لتخزين كل حرف.وهذا يعني أنه يمكن تعريف 65,536 حرفًا مختلفًا، لذا يمكن تغطية جميع الأحرف تقريبًا باستخدام Unicode.إذا كان جهازي كمبيوتر يستخدمان Unicode، فسيتم تمثيل كل رمز بنفس الطريقة ولن تكون هناك حاجة إلى تحويل - هذه هي الفكرة وراء Unicode.

يحتوي SQL Server على فئتين من أنواع بيانات الأحرف:

• غير Unicode (char، varchar، والنص)
• Unicode (nchar، nvarchar، وntext)

إذا كنا بحاجة إلى حفظ بيانات الأحرف من بلدان متعددة، فاستخدم دائمًا Unicode.

Answer 12

بالرغم من NVARCHAR مخازن Unicode، يجب أن تفكر في المساعدة في الترتيب كما يمكنك استخدامها VARCHAR وحفظ بياناتك بلغاتك المحلية.

فقط تخيل السيناريو التالي.

ترتيب قاعدة البيانات الخاصة بك هو اللغة الفارسية ويمكنك حفظ قيمة مثل "علی" (الكتابة الفارسية لعلي) في VARCHAR(10) نوع البيانات.لا توجد مشكلة ويستخدم نظام إدارة قواعد البيانات (DBMS) ثلاث بايتات فقط لتخزينه.

ومع ذلك، إذا كنت تريد نقل بياناتك إلى قاعدة بيانات أخرى ورؤية النتيجة الصحيحة، فيجب أن تحتوي قاعدة بيانات الوجهة الخاصة بك على نفس الترتيب مثل الهدف الفارسي في هذا المثال.

إذا كان الترتيب المستهدف مختلفًا، فسترى بعض علامات الاستفهام (؟) في قاعدة البيانات الهدف.

أخيرًا، تذكر إذا كنت تستخدم قاعدة بيانات ضخمة مخصصة لاستخدام لغتك المحلية، فإنني أوصي باستخدام الموقع بدلاً من استخدام مسافات كثيرة جدًا.

أعتقد أن التصميم يمكن أن يكون مختلفًا.يعتمد ذلك على البيئة التي تعمل بها.

Answer 13

يجب أن أقول هنا (أدرك أنني ربما سأفتح نفسي أمام قائمة!) ، ولكن بالتأكيد المرة الوحيدة التي NVARCHAR هو في الواقع أكثر مفيد (لاحظ أكثر هناك!) من VARCHAR هو عندما تكون كافة عمليات الترتيب على كافة الأنظمة التابعة وداخل قاعدة البيانات نفسها هي نفسها...؟إذا لم يكن الأمر كذلك، فيجب أن يحدث تحويل الترتيب على أي حال، وهذا ما يحدث VARCHAR قابلة للحياة تماما كما NVARCHAR.

إضافة إلى ذلك، بعض أنظمة قواعد البيانات، مثل خادم SQL (قبل 2012) يكون حجم الصفحة تقريبًا.8 ك.لذا، إذا كنت تتطلع إلى تخزين البيانات القابلة للبحث والتي لا يتم الاحتفاظ بها في شيء مثل TEXT أو NTEXT الميدان ثم VARCHAR يوفر مساحة تبلغ 8 كيلو بايت كاملة بينما NVARCHAR يوفر فقط 4K (مضاعفة البايتات، ومضاعفة المساحة).

أفترض، لتلخيص، أن استخدام أي منهما يعتمد على:

• المشروع أو السياق
• بنية تحتية
• نظام قاعدة البيانات

Answer 14

يتبع الفرق بين نوع بيانات Sql Server VARCHAR وNVARCHAR.هنا يمكنك أن ترى بطريقة وصفية للغاية.

في عام، يقوم nvarchar بتخزين البيانات بتنسيق Unicode، لذا، إذا كنت ستقوم بتخزين بيانات متعددة اللغات (أكثر من لغة واحدة) في عمود بيانات، فأنت بحاجة إلى متغير N.

Answer 15

لقد ألقيت نظرة على الإجابات ويبدو أن الكثير منها يوصي باستخدامها nvarchar زيادة varchar, ، لأن المساحة لم تعد مشكلة بعد الآن، لذلك ليس هناك أي ضرر في تمكين Unicode للحصول على مساحة تخزين إضافية قليلة.حسنًا، هذا ليس صحيحًا دائمًا عندما تريد تطبيق فهرس على العمود الخاص بك.لدى SQL Server حد يبلغ 900 بايت لحجم الحقل الذي يمكنك فهرسته.لذلك إذا كان لديك varchar(900) لا يزال بإمكانك فهرسته، ولكن لا varchar(901).مع nvarchar, ، تم تقليل عدد الأحرف إلى النصف، حتى تتمكن من فهرسة ما يصل إلى nvarchar(450).فإذا كنت واثقاً من أنك لا تحتاج nvarchar, ، لا أنصح باستخدامه.

بشكل عام، في قواعد البيانات، أوصي بالالتزام بالحجم الذي تحتاجه، لأنه يمكنك دائمًا التوسع.على سبيل المثال، اعتقد أحد زملائي في العمل ذات مرة أنه لا ضرر من التعاطي nvarchar(max) لعمود، حيث ليس لدينا مشكلة في التخزين على الإطلاق.لاحقًا، عندما حاولنا تطبيق فهرس على هذا العمود، رفض SQL Server ذلك.ومع ذلك، إذا بدأ بـ حتى varchar(5), ، كان بإمكاننا ببساطة توسيعها لاحقًا إلى ما نحتاج إليه دون حدوث مثل هذه المشكلة التي ستتطلب منا القيام بخطة ترحيل ميدانية لإصلاح هذه المشكلة.

Answer 16

الفرق الرئيسي بين Varchar(n) و nvarchar(n) يكون:

Varchar(حجم متغير الطول، بيانات أحرف غير Unicode) يصل إلى 8000.1. إنه نوع بيانات متغير الطول

2. يستخدم لتخزين أحرف غير Unicode

3. يشغل بايت واحد من المساحة لكل حرف

Nvarchar:بيانات أحرف Unicode ذات الطول المتغير.

1. إنه نوع بيانات متغير الطول

2. يستخدم لتخزين أحرف Unicode.

3. يتم تخزين البيانات بترميز Unicode.كل لغة مدعومة.(على سبيل المثال اللغات العربية والألمانية والهندية وغيرها)

Answer 17

يوصي Jeffrey L Whitledge الحاصل على درجة سمعة تبلغ 47000 تقريبًا باستخدام nvarchar

يوصي Solomon Rutzky الحاصل على درجة سمعة تصل إلى 33200 تقريبًا بما يلي:لا تستخدم NVARCHAR دائمًا.وهذا موقف/نهج خطير للغاية، ومكلف في كثير من الأحيان.

ما هي الاختلافات الرئيسية في الأداء بين أنواع بيانات varchar وnvarchar SQL Server؟

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

كلا الشخصين يتمتعان بسمعة طيبة، ما الذي يختاره مطور قاعدة بيانات خادم SQL التعليمي؟

هناك العديد من التحذيرات في الإجابات والتعليقات حول مشكلات الأداء إذا لم تكن متسقًا في الاختيارات.

هناك تعليقات مؤيدة/يخدع nvarchar للأداء.

هناك تعليقات مؤيدة/يخدع varchar للأداء.

لدي مطلب خاص لجدول يحتوي على عدة مئات من الأعمدة، وهو أمر غير معتاد في حد ذاته؟

أختار varchar لتجنب الاقتراب من الحد الأقصى لحجم سجل جدول 8060 بايت لـ SQL*server 2012.

بالنسبة لي، استخدام nvarchar يتجاوز الحد الأقصى البالغ 8060 بايت.

أعتقد أيضًا أنه يجب علي مطابقة أنواع البيانات الخاصة بجداول التعليمات البرمجية ذات الصلة بأنواع بيانات الجدول المركزي الأساسي.

لقد رأيت استخدام عمود varchar في مكان العمل هذا، حكومة جنوب أستراليا، من قبل مطوري قواعد البيانات ذوي الخبرة السابقين، حيث سيكون عدد صفوف الجدول عدة ملايين أو أكثر (وعدد قليل جدًا من أعمدة nvarchar، إن وجدت، في هذه الأعمدة الكبيرة جدًا الجداول)، لذلك ربما تصبح أحجام صفوف البيانات المتوقعة جزءًا من هذا القرار.

Answer 18

nvarchar آمن للاستخدام مقارنة بـ varchar من أجل جعل الكود الخاص بنا خاليًا من الأخطاء (النوع غير متطابق) لأن nvarchar يسمح بأحرف Unicode أيضًا.عندما نستخدم where الشرط في استعلام SQL Server وإذا كنا نستخدم = المشغل، وسوف يلقي خطأ في بعض الأحيان.السبب المحتمل لذلك هو أنه سيتم تحديد عمود التعيين الخاص بنا varchar.إذا حددناها في nvarchar هذه المشكلة لا تحدث.ما زلنا متمسكين به varchar وتجنب هذه المشكلة من الأفضل أن نستخدمها LIKE الكلمة الرئيسية بدلا من =.