عندما يجب أن نستخدم NVARCHAR/NCHAR بدلا من VARCHAR/شار في SQL Server?

Question

هل هناك قاعدة يجب أن تستخدم Unicode أنواع ؟

لقد رأيت أن معظم اللغات الأوروبية (الألمانية, الإيطالية, الإنجليزية, ...) بخير في نفس قاعدة البيانات في الأعمدة VARCHAR.

أنا أبحث عن شيء مثل:

1. إذا كان لديك الصينية --> استخدام NVARCHAR
2. إذا كان لديك الألمانية والعربية --> استخدام NVARCHAR

ماذا عن جمع من سيرفر/قاعدة البيانات ؟

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

Answer 1

السبب الحقيقي الذي تريد استخدامه NVARCHAR هو عندما يكون لديك مختلفة لغات في نفس العمود ، تحتاج إلى معالجة الأعمدة في T-SQL دون فك, كنت تريد أن تكون قادرا على رؤية البيانات "أصلا" في صواريخ أرض-أرض ، أو كنت تريد أن توحيد في Unicode.

إذا كنت علاج قاعدة بيانات البكم التخزين ، فمن الممكن تماما لتخزين واسعة من سلاسل مختلفة (حتى طول متغير) ترميزات في VARCHAR (على سبيل المثال UTF-8).المشكلة تأتي عندما تحاول ترميز وفك ترميز خاصة إذا كان رمز صفحة عن مختلف الصفوف.وهذا يعني أيضا أن SQL Server سوف لا تكون قادرة على التعامل مع البيانات بسهولة لأغراض الاستعلام داخل T-SQL على (يحتمل أن تكون مغايرة) ترميز الأعمدة.

باستخدام NVARCHAR يتجنب كل هذا.

أنصح NVARCHAR أي العمود الذي سيكون البيانات التي أدخلها المستخدم في ذلك وهو نسبيا غير المقيد.

أنصح VARCHAR أي العمود الذي هو مفتاح الطبيعية (مثل لوحة ترخيص المركبات ، SSN, الرقم التسلسلي, خدمة الوسم, رقم الطلب, مطار رمز النداء ، الخ) التي عادة ما يتم تعريفها و مقيدة معيار أو التشريعات أو الاتفاقية.أيضا VARCHAR على المستخدم إدخالها ، مقيدة جدا (مثل رقم الهاتف) أو رمز (نشط/مغلقة, Y/N, M/F M/S/D/W ، إلخ).هناك على الإطلاق أي سبب استخدام NVARCHAR لأولئك.

وذلك على قاعدة بسيطة:

VARCHAR عندما يضمن أن تكون مقيدة NVARCHAR خلاف ذلك

Answer 2

يجب عليك استخدام NVARCHAR في أي وقت لديك لتخزين متعددة اللغات.أعتقد أن لديك لاستخدامها اللغات الآسيوية ولكن لا اقتبس لي على ذلك.

هنا المشكلة إذا كنت تأخذ الروسية على سبيل المثال وتخزينها في varchar سوف يكون على ما يرام طالما يمكنك تحديد الكود الصحيح الصفحة.ولكن دعونا نقول الخاصة بك باستخدام الافتراضي الإنجليزية تثبيت sql, ثم الأحرف الروسية لن يتم التعامل معها بشكل صحيح.إذا كنت تستخدم NVARCHAR() أنهم سوف يتم التعامل معها بشكل صحيح.

تحرير

حسنا اسمحوا لي أن أقتبس MSDN و مايبي كنت محددة ولكن كنت لا ترغب في تخزين أكثر من واحد صفحة التعليمات البرمجية في varcar العمود ، في حين يمكنك يجب أن لا

عند التعامل مع البيانات النصية التي يتم المخزنة في شار varchar ، varchar(max) أو نوع بيانات نص ، أهم الحد للنظر في هو أن المعلومات الوحيدة من واحد صفحة التعليمات البرمجية يمكن التصديق عليها من قبل النظام.(يمكنك تخزين البيانات من رمز متعددة الصفحات ، ولكن ليس هذا هو الموصى بها.) الدقيق صفحة التعليمات البرمجية المستخدمة للتحقق من وتخزين البيانات يعتمد على ترتيب العمود.إذا مستوى العمود ترتيب لم تعريف ترتيب نسخ قاعدة البيانات يتم استخدامه.لتحديد صفحة التعليمات البرمجية يستخدم عمود محدد ، يمكن استخدام COLLATIONPROPERTY وظيفة, كما هو موضح في التالي أمثلة التعليمات البرمجية:

وهنا بعض مزيد من المعلومات:

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

حتى الجورجية أو الهندية حقا بحاجة إلى أن تكون تخزين nvarchar.العربية هي أيضا مشكلة:

مشكلة أخرى قد تواجه هو عدم القدرة على تخزين البيانات عندما لا جميع الشخصيات التي ترغب في دعم الواردة في التعليمات البرمجية الصفحة.في كثير من الحالات, Windows ترى خاص صفحة التعليمات البرمجية أن يكون "أفضل صالح" صفحة التعليمات البرمجية ، مما يعني أن هناك لا يوجد ضمان أن يمكنك الاعتماد على صفحة التعليمات البرمجية للتعامل مع جميع النص ؛ فمن مجرد أفضل واحد المتاحة.وهو مثال على ذلك هو الكتابة العربية:وهو يدعم مجموعة واسعة من اللغات ، بما في ذلك البلوشي ، البربر ، الفارسية ، كشمير, الكازاخستانية, السنهالية, لغة الباشتو ، السندية ، اليوغور, الأردية, وأكثر من ذلك.كل من هذه لغات إضافية الشخصيات تتجاوز تلك التي في العربية اللغة كما هو محدد في نظام التشغيل Windows رمز الصفحة 1256.إذا كنت في محاولة لتخزين هذه الأحرف الزائدة في Unicode العمود الذي يحتوي على اللغة العربية ترتيب الأحرف تحويلها إلى علامات استفهام.

شيء أن نأخذ في الاعتبار عند استخدام يونيكود على الرغم من أن يمكنك تخزين لغات مختلفة في عمود واحد يمكنك فقط نوع واحد وتصنيفها.هناك بعض اللغات التي تستخدم الحروف اللاتينية ولكن لا نوع مثل اللغات اللاتينية الأخرى.لهجات هي مثال جيد على هذا ، وأنا لا يمكن أن نتذكر على سبيل المثال ولكن كان هناك أوروبا الشرقية اللغة التي Y لم النوع مثل الإنجليزية Y.ثم هناك الإسبانية الفصل الذي الإسبانية المستخدمين تتوقع أن يتم فرزها بعد ساعة.

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

Answer 3

اليونانية سوف تحتاج إلى UTF-8 على N عمود أنواع:αβγ ;)

Answer 4

جوش يقول:"....شيء أن نأخذ في الاعتبار عند استخدام يونيكود على الرغم من أن يمكنك تخزين لغات مختلفة في عمود واحد يمكنك فقط نوع واحد وتصنيفها.هناك بعض اللغات التي تستخدم الحروف اللاتينية ولكن لا نوع مثل اللغات اللاتينية الأخرى.لهجات هي مثال جيد على هذا ، وأنا لا يمكن أن نتذكر على سبيل المثال ولكن كان هناك أوروبا الشرقية اللغة التي Y لم النوع مثل الإنجليزية Y.ثم هناك الإسبانية الفصل الذي الإسبانية المستخدمين تتوقع أن يتم فرزها بعد ساعة."

أنا أصلي في اللغة الإسبانية و "الفصل" ليس رسالة ولكن اثنين من "ج" و "ح" و الأبجدية الإسبانية مثل:abcdefghijklmn ñ opqrstuvwxyz نحن لا نتوقع "ch" بعد "ح" ولكن "أنا" الأبجدية هو نفسه كما هو الحال في اللغة الإنجليزية ما عدا لبنان أو في HTML "n ;"

اليكس

Answer 5

TL;DR;
Unicode - (nchar, nvarchar ، ntext)
Unicode - (char, varchar و نص).

من MSDN

الترتيب في SQL Server توفير قواعد الفرز, حالة, و لهجة حساسية خصائص البيانات الخاصة بك.الترتيب التي تستخدم مع حرف أنواع البيانات مثل شار و varchar إملاء صفحة التعليمات البرمجية وما يقابلها من الحروف التي يمكن أن تكون ممثلة على تلك البيانات نوع.

على افتراض أنك تستخدم SQL الافتراضي ترتيب SQL_Latin1_General_CP1_CI_AS ثم النصي التالي يجب طباعة جميع الرموز التي يمكنك تناسب في VARCHAR لأنه يستخدم بايت واحد لتخزين حرف واحد (256 المجموع) إذا كنت لا ترى ذلك على قائمة مطبوعة - تحتاج NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

إذا قمت بتغيير ترتيب أن يتيح القول اليابانية ستلاحظ أن جميع الأوروبي غريب الحروف تحولت إلى وضعها الطبيعي و بعض الرموز في ? علامات.

Unicode هي معيار التعيين رمز النقاط على الحروف.لأن وهي مصممة لتغطية جميع الشخصيات من جميع اللغات هناك حاجة مختلفة صفحات التعليمات البرمجية للتعامل مع مختلف مجموعات من الأحرف.إذا قمت بتخزين البيانات الشخصية التي تعكس متعددة لغات, دائما استخدام Unicode أنواع البيانات (nchar, nvarchar ، ntext) بدلا من بيانات Unicode أنواع (char, varchar و نص).

وإلا الفرز سوف تذهب غريب.