يرجى تقديم المشورة:معرف SQL Server مقابل مفاتيح المعرف الفريد عند استخدام Entity Framework

Question

أنا بصدد تصميم نظام معقد إلى حد ما.أحد اهتماماتنا الأساسية هو دعم النسخ المتماثل من نظير إلى نظير لـ SQL Server.والفكرة هي دعم عدة عقد منفصلة جغرافيا.

كان الاهتمام الثانوي هو استخدام ORM حديث في الطبقة الوسطى.لقد كان خيارنا الأول دائمًا هو Entity Framework، ويرجع ذلك أساسًا إلى أن المطورين يحبون العمل معه.(إنهم يحبون دعم LiNQ.)

إذن هذه هي المشكلة:

مع أخذ النسخ المتماثل من نظير إلى نظير في الاعتبار، قررت استخدام المعرف الفريد مع القيمة الافتراضية لـ newsequentialid() للمفتاح الأساسي لكل جدول.يبدو أن هذا يوفر توازنًا جيدًا بين تجنب الاصطدامات الرئيسية وتقليل تجزئة الفهرس.

ومع ذلك، اتضح أن الإصدار الحالي من Entity Framework يحتوي على تقييد غريب جدا:إذا كان عمود مفتاح الكيان عبارة عن معرف فريد (GUID)، فلا يمكن تكوينه لاستخدام القيمة الافتراضية (newsequentialid()) التي توفرها قاعدة البيانات.يجب أن تقوم طبقة التطبيق بإنشاء المعرف الفريد العمومي (GUID) وملء قيمة المفتاح.

إذن هنا النقاش:

1. التخلي عن Entity Framework واستخدام ORM آخر:
   • استخدم NHibernate والتخلي عن دعم LiNQ
   • استخدم linq2sql والتخلي عن الدعم المستقبلي (ناهيك عن الارتباط بـ SQL Server على قاعدة البيانات)
2. تخلى عن المعرفات الفريدة العمومية (GUIDs) واتبع إستراتيجية PK أخرى
3. ابتكر طريقة لإنشاء المعرفات الفريدة العمومية (GUIDs) المتسلسلة (COMBs؟) في طبقة التطبيق

أنا أميل نحو الخيار 1 مع linq2sql (يحب المطورون حقًا linq2[الأشياء]) و3.ويرجع ذلك أساسًا إلى أنني جاهل إلى حد ما بالاستراتيجيات الرئيسية البديلة التي تدعم مخطط النسخ المتماثل الذي نهدف إليه مع الحفاظ على الأمور عقلانية من منظور المطور.

أي فكرة أو رأي سيكون موضع تقدير كبير.

Answer 1

هناك خيار آخر (غير متاح عند نشر هذا) وهو الترقية إلى EF 4، الذي يدعم المعرفات الفريدة العمومية (GUIDs) التي ينشئها الخادم.

Answer 2

أنا أؤيد اقتراح كريج - الخيار 4.

يمكنك دائمًا استخدام عمود GUID، الذي يتم ملؤه بالطبقة الوسطى، باعتباره مفتاحك الأساسي (وهذا بناء منطقي).

لتجنب الفهرس الضخم (وبالتالي:الجدول) التجزئة، استخدم مفتاحًا آخر (من الأفضل عمود معرف INT) كمفتاح التجميع - وهو بناء قاعدة بيانات فعلية، يمكن فصله عن المفتاح الأساسي.

بشكل افتراضي، المفتاح الأساسي هو مفتاح التجميع - ولكن لا يجب أن يكون الأمر بهذه الطريقة.في الواقع، لقد قمت بتحسين الأداء وخفضت التجزئة بشكل كبير من خلال القيام بذلك على قاعدة بيانات "ورثتها" - أضف عمود INT IDENTITY ووضع مفتاح التجميع على INT الصغير والمتزايد باستمرار والذي لا يتغير أبدًا - يعمل مثل السحر!

مارك

Answer 3

هاه؟أعتقد أن خياراتك الثلاثة هي خيار خاطئ.النظر في الخيار 4:

4) استخدم إطار الكيان مع غير متسلسل, ، المعرفات الفريدة العمومية (GUIDs) التي أنشأها العميل.

لا يمكن لـ EF رؤية المعرفات الفريدة العمومية (GUID) التي تم إنشاؤها بواسطة خادم قاعدة البيانات للصفوف الجديدة التي تم إدراجها بواسطة الإطار نفسه, بالتأكيد، ولكنك لا تحتاج إلى إنشاء المعرفات الفريدة العمومية (GUIDs) على خادم قاعدة البيانات.يمكنك إنشاؤها على العميل عند إنشاء مثيلات الكيان الخاص بك.بيت القصيد من GUID هو أنه لا يهم المكان الذي تقوم بإنشائه.أما بالنسبة للمعرفات الفريدة العمومية (GUIDs) التي تم إنشاؤها بواسطة قاعدة بيانات منسوخة، فسوف تراها EF بشكل جيد.

لن تكون المعرفات الفريدة العمومية (GUID) من جانب العميل متسلسلة (استخدم Guid.NewGuid())، ولكنها ستكون عالمية ومضمونة وفريدة.

نحن نفعل ذلك في برامج الشحن والإنتاج مع النسخ المتماثل.هو - هي يفعل عمل.

Answer 4

لماذا لا تستخدم عمود الهوية؟إذا كنت تقوم بدمج النسخ المتماثل، فيمكنك جعل كل نظام يبدأ من بذرة منفصلة ويعمل في اتجاه واحد (على سبيل المثال.تبدأ العقدة أ عند 1 وتضيف 1، وتبدأ العقدة ب عند 0 وتطرح واحدًا)...

Answer 5

يمكنك استخدام الإجراءات المخزنة إذا كنت عالقًا في استخدام NewSequentialID().يمكنك ربط أعمدة النتائج من الإجراء بالخاصية المناسبة وبمجرد إدراج المعرف الفريد العمومي (GUID) الذي تم إنشاؤه بواسطة SQL سيتم تغذيته مرة أخرى في الكائن.

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

يوجد مثال خطوة بخطوة على http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspx وهو أمر واضح ومباشر.

Answer 6

استخدم newseqid مع orm الخاص بك (ليس الأمر بهذه الصعوبة) مع linq