أوس - 2 و سكل سيرفر

Question

بينما خيارات البحث لتخزين معظمها الإنجليزية ولكن في بعض الأحيان لا البيانات في قاعدة بيانات سكل سيرفر التي يمكن أن تكون كبيرة جدا ، وأنا يميل نحو تخزين معظم البيانات سلسلة كما أوتف-8 المشفرة.

ومع ذلك ، اختارت مايكروسوفت أوكس-2 لأسباب لا أفهم تماما الذي يسبب لي أن تخمين الثاني أن يميل.وثائق ل سكل سيرفر 2012 لا تظهر كيفية إنشاء أوتف-8 أودت, ، ولكن القرار ل أوس - 2 يفترض أن يسود سكل سيرفر.

ويكيبيديا (الذي يلاحظ بشكل مثير للاهتمام أن أوس-2 عفا عليها الزمن لصالح أوتف-16) يلاحظ أن أوتف-8 هو مجموعة أحرف متغيرة العرض قادرة على ترميز أي نقطة بيانات يونيكود وأنه provides the de facto standard encoding for interchange of Unicode text.لذلك ، فإنه يشعر مثل أي حرف ونيكود يمكن أن تكون ممثلة في أوتف-8 ، وبما أن معظم النص سيكون الإنجليزية ، فإن التمثيل يكون ما يقرب من ضعف المدمجة كما هو الحال مع أوكس-2 (وأنا أعلم القرص هو "رخيصة" ، ولكن ذاكرة التخزين المؤقت القرص ليست ، والذاكرة ليست بالمقارنة مع أحجام البيانات أنا أتعامل معها.تتحلل العديد من العمليات بشكل كبير عندما تكون مجموعة العمل أكبر من ذاكرة الوصول العشوائي المتاحة).

ما هي المشاكل التي قد أواجهها من خلال السباحة في تيار جامعة كاليفورنيا-2?

Answer 1

تخزين معظمها الإنجليزية ولكن في بعض الأحيان لا البيانات في قاعدة بيانات سكل سيرفر التي يمكن أن تكون كبيرة جدا ، وأنا يميل نحو تخزين معظم البيانات سلسلة كما أوتف-8 المشفرة.

وخلافا لبعض ردبس الأخرى التي تسمح لاختيار ترميز ، سكل سيرفر مخازن بيانات ونيكود فقط في أوتف-16 (ليتل إنديان) ، والبيانات غير ونيكود في ترميز 8 بت (أسي الموسعة ، دبكس ، أو إبكديك) لأي صفحة التعليمات البرمجية هو ضمني من قبل ترتيب الحقل.

اختارت مايكروسوفت جامعة كاليفورنيا-2 لأسباب لا أفهمها تماما

قرارهم ل اختر أوكس-2 من المنطقي بما فيه الكفاية بالنظر إلى أن أوتف-16 قدم في منتصف عام 1996 والمحددة بالكامل في عام 2000.تستخدم الكثير من الأنظمة الأخرى (أو تستخدم) أيضا (يرجى الاطلاع على: https://en.wikipedia.org/wiki/UTF-16#Usage).قرارهم ل تابع مع أنه قد يكون أكثر مشكوك فيه ، على الرغم من أنه ربما يرجع إلى ويندوز و.نيت يجري أوتف-16.التخطيط المادي للبايت هو نفسه بين أوكس - 2 و أوتف-16 ، لذلك رفع مستوى النظم من أوكس-2 لدعم أوتف-16 يجب أن تكون وظيفية بحتة دون الحاجة إلى تغيير أي بيانات موجودة.

وثائق ل سكل سيرفر 2012 لا تظهر كيفية إنشاء أوتف-8 أودت,

أم ، لا.إنشاء نوع مخصص المعرفة من قبل المستخدم عبر سكلر هو لا, ، بأي شكل من الأشكال ، سوف تحصل على بديل من أي نوع أصلي.إنه مفيد جدا لإنشاء شيء للتعامل مع البيانات المتخصصة.لكن السلاسل ، حتى ذات الترميز المختلف ، بعيدة كل البعد عن التخصص.سيؤدي السير في هذا المسار لبيانات السلسلة إلى تدمير أي قدر من قابلية استخدام نظامك ، ناهيك عن الأداء حيث لن تتمكن من استخدامه أي المدمج في وظائف سلسلة.إذا كنت قادرا على حفظ أي شيء على مساحة القرص ، فسيتم مسح هذه المكاسب بما قد تخسره في الأداء العام.يتم تخزين أودت عن طريق تسلسل إلى VARBINARY.لذلك من أجل القيام به أي مقارنة سلسلة أو الفرز ، خارج مقارنة "ثنائي" / "ترتيبي" ، سيكون لديك لتحويل جميع القيم الأخرى ، واحدا تلو الآخر ، والعودة إلى أوتف-8 ثم القيام سلسلة مقارنة التي يمكن حساب الاختلافات اللغوية.

أيضا ، أن "الوثائق" هي في الحقيقة مجرد نموذج رمز / دليل على الأشياء المفهوم.تمت كتابة الرمز في عام 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) ل سكل سيرفر 2005.رأيت نصا لاختبار الوظيفة ، لكن لا شيء يتضمن الأداء.

ولكن القرار ل أوس - 2 يفترض أن يسود سكل سيرفر.

نعم ، كثيرا جدا.افتراضيا ، والتعامل مع وظائف المدمج في هو فقط ل أوس-2.ولكن بدءا من سكل سيرفر 2012 ، يمكنك الحصول عليها للتعامل مع كامل أوتف-16 مجموعة الأحرف (حسنا ، اعتبارا من ونيكود الإصدار 5 أو 6 ، اعتمادا على نظام التشغيل الخاص بك وإصدار الإطار الصافي) باستخدام واحدة من التصنيفات التي لها اسم تنتهي في _SC (أي.الأحرف التكميلية).

ويكيبيديا ...ويلاحظ أن أوس-2 عفا عليها الزمن لصالح أوتف-16

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

ويكيبيديا ...يلاحظ أن أوتف-8 هو مجموعة أحرف متغيرة العرض قادرة على ترميز أي نقطة بيانات يونيكود

صحيح ، على الرغم من مضللة.نعم ، أوتف-8 هو متغير العرض ، ولكن أوتف - 16 هو أيضا متغير طفيف لأن جميع الأحرف التكميلية تتكون من نقطتين رمز مزدوج البايت.وبالتالي أوتف - 16 يستخدم إما 2 أو 4 بايت لكل رمز ، على الرغم من أوس-2 هو دائما 2 بايت.لكن هذا ليس الجزء المضلل.ما هو مضلل هو ضمنا أن أي ترميز ونيكود أخرى ليست قادرة على ترميز جميع نقاط التعليمات البرمجية الأخرى.في حين أوس-2 يمكن الاحتفاظ بها ولكن لا تفسيرها ، على حد سواء أوتف-16 و أوتف-32 يمكن على حد سواء خريطة جميع نقاط رمز ونيكود ، تماما مثل أوتف-8.

وأنه [إد:أوتف - 8] يوفر الترميز القياسي الفعلي لتبادل نص يونيكود.

قد يكون هذا صحيحا ، لكنه غير ذي صلة تماما من منظور تشغيلي.

بدا الامر وكأننا أي حرف يونيكود يمكن أن تكون ممثلة في أوتف-8

مرة أخرى ، صحيح ، ولكن غير ذي صلة تماما منذ أوتف-16 و أوتف-32 أيضا تعيين جميع نقاط رمز ونيكود.

نظرا لأن معظم النصوص ستكون باللغة الإنجليزية ، فسيكون التمثيل مضغوطا مرتين تقريبا كما هو الحال مع جامعة كاليفورنيا-2

اعتمادا على الظروف ، قد يكون هذا صحيحا جدا ، وأنت محق في القلق بشأن هذا الاستخدام المهدر.ومع ذلك ، كما ذكرت في السؤال الذي يؤدي إلى هذا واحد ( أوتف-8 الدعم ، سكل سيرفر 2012 و أوتف 8 سترينغ أودت ) ، لديك بعض الخيارات للتخفيف من مقدار المساحة المهدرة إذا كان من الممكن احتواء معظم الصفوف VARCHAR ومع ذلك ، يجب أن يكون البعض NVARCHAR.الخيار الأفضل هو تمكين ضغط الصف أو ضغط الصفحة (تحرير المؤسسة فقط!).بدءا من سكل سيرفر 2008 ر2 ، فإنها تسمح غير ماكس NVARCHAR الحقول لاستخدام "مخطط ضغط قياسي ل ونيكود" الذي هو على الأقل جيدة مثل أوتف-8 ، وفي بعض الحالات هو أفضل من أوتف-8. NVARCHAR(MAX) لا يمكن استخدام الحقول هذا الضغط الهوى, ، ولكن بياناتهم في الصف يمكن أن تستفيد من الصف العادي و / أو ضغط الصفحة.يرجى الاطلاع على ما يلي للحصول على وصف لهذا الضغط ومخطط يقارن أحجام البيانات لـ:الخام أوس-2 / أوتف-16 ، أوتف-8 ، و أوكس-2 / أوتف-16 مع تمكين ضغط البيانات.

سكل سيرفر 2008 آر 2 - يو سي إس 2 ضغط ما هو-التأثير على أنظمة ساب

يرجى أيضا الاطلاع على صفحة مسن ل ضغط البيانات لمزيد من التفاصيل كما أن هناك بعض القيود (أبعد من كونها متاحة فقط في الطبعة المؤسسة - ولكن إتاحتها ل الكل طبعات بدءا من سكل سيرفر 2016 ، سب 1 !!) وبعض الظروف التي قد يؤدي فيها الضغط إلى تفاقم الأمور.

أعلم أن القرص"رخيص"

صحة هذا البيان يعتمد على كيفية تعريف واحد "القرص".إذا كنت تتحدث من حيث أجزاء السلع التي يمكنك شراء من على الرف في متجر لاستخدامها في سطح المكتب / الكمبيوتر المحمول, ثم تأكد.ولكن ، إذا كان يتحدث من حيث التخزين على مستوى المؤسسة التي سيتم استخدامها لأنظمة الإنتاج الخاصة بك ، ثم المتعة شرح لمن يتحكم في الميزانية التي لا ينبغي أن يرفض سان مليون دولار زائد التي تريدها لأنها "رخيصة"؛ -).

ما هي المشاكل التي قد أواجهها من خلال السباحة في تيار جامعة كاليفورنيا-2?

لا شيء يمكنني التفكير فيه.حسنا ، طالما أنك لا تتبع أي نصيحة رهيبة للقيام بشيء مثل تنفيذ هذا أودت ، أو تحويل جميع السلاسل إلى VARBINARY, ، أو باستخدام NVARCHAR(MAX) لجميع حقول السلسلة؛ -).ولكن من كل الأشياء التي يمكن أن تقلق ، سكل سيرفر باستخدام أوس - 2 / أوتف-16 لا ينبغي أن يكون واحدا منهم.

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

---

تحديث 2018-10-02

في حين أن هذا ليس خيارا قابلا للتطبيق حتى الآن ، سكل سيرفر 2019 يقدم الدعم الأصلي ل أوتف-8 في VARCHAR / CHAR أنواع البيانات.يوجد حاليا الكثير من الأخطاء معها لاستخدامها ، ولكن إذا تم إصلاحها، فهذا خيار لـ بعض سيناريوهات.يرجى الاطلاع على منصبي،"دعم أوتف-8 الأصلي في سكل سيرفر 2019:المخلص أو النبي الكذاب?"،للحصول على تحليل مفصل لهذه الميزة الجديدة.

Answer 2

ماذا تقصد ب "السباحة حتى دفق UCS-2"؟

هنا خياراتك:

• استخدم Collations 2012 _SC الجديد ( https://msdn.microsoft.com/en-us/library/ms143726.aspx ).هذه الفكرة تأتي من Srutzky.يجب عليك التحقق من إجابته.هذا هو أفضل حلا أفضل.

  غير مستحسن ولكن ممكن:

  • تنفيذ UDT.سيكون هذا الكثير من العمل وستقوم بفقدان الدعم (أو رسم الخرائط وبالتأكيد بعض ميزات SQL Server التي تعمل على الأنواع الأصلية).
  • استخدام varbinary (كحد أقصى): يتطلب منك القيام برمز تحويل مخصص.لا يوجد فهرسة النطاق.
  • استخدم nvarchar (n) وتشغيل ضغط الصف.بدءا من SQL Server 2008 R2، سيستخدم هذا الترميز غير المضغوط مثل UTF-8.ولكن هذا يتطلب طبعة المؤسسات.

    انظر التعليقات على القراءة عن العيوب الشديدة التي هذه الأساليب لها.