بديل مقابل.المفاتيح الطبيعية/التجارية [مغلق]

Question

ها نحن نعود مرة أخرى، الحجة القديمة لا تزال قائمة...

هل من الأفضل أن يكون لدينا مفتاح عمل كمفتاح أساسي، أم نفضل أن يكون لدينا معرف بديل (أي؟هوية SQL Server) مع قيد فريد في حقل مفتاح العمل؟

من فضلك، تقديم أمثلة أو أدلة لدعم نظريتك.

Answer 1

كلاهما.هل لديك كعكة الخاص بك وأكله.

تذكر أنه لا يوجد شيء مميز بشأن المفتاح الأساسي، باستثناء أنه يتم تصنيفه على هذا النحو.إنه ليس أكثر من قيد NOT NULL UNIQUE، ويمكن أن يحتوي الجدول على أكثر من قيد.

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

Answer 2

فقط بعض الأسباب لاستخدام المفاتيح البديلة:

1. استقرار:إن تغيير المفتاح بسبب حاجة تجارية أو طبيعية سيؤثر سلبًا على الجداول ذات الصلة.نادرًا ما تحتاج المفاتيح البديلة إلى التغيير، هذا إن وجدت، لأنه لا يوجد معنى مرتبط بالقيمة.

2. مؤتمر:يتيح لك الحصول على اصطلاح تسمية عمود المفتاح الأساسي القياسي بدلاً من الاضطرار إلى التفكير في كيفية ضم الجداول بأسماء مختلفة لـ PKs الخاصة بها.

3. سرعة:اعتمادًا على قيمة ونوع PK، قد يكون المفتاح البديل لعدد صحيح أصغر وأسرع في الفهرسة والبحث.

Answer 3

يبدو أنه لم يقل أحد أي شيء حتى الآن لدعم المفاتيح غير البديلة (أتردد في قول المفاتيح "الطبيعية").إذن هنا يذهب...

أ عيب من المفاتيح البديلة هو أنهم كذلك لا معنى له (يستشهد بها البعض على أنها ميزة، ولكن...).يفرض عليك هذا أحيانًا ضم عدد أكبر من الجداول في استعلامك أكثر مما ينبغي حقًا.يقارن:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

ضد:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

ما لم يعتقد أي شخص جديًا أن ما يلي فكرة جيدة؟:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"لكن" شخص ما سيقول ، "ماذا يحدث عندما يتغير رمز myProject أو صالح أو HR؟" الذي سيكون إجابتي:"لماذا سوف يحتاج لتغييره؟" هذه ليست مفاتيح "طبيعية" بمعنى أن بعض الهيئات الخارجية سوف تشرع من الآن فصاعدا أنه يجب إعادة ترميز "صالح" على أنه "جيد".فقط نسبة صغيرة من المفاتيح "الطبيعية" تندرج ضمن هذه الفئة - SSN والرمز البريدي هما الأمثلة المعتادة.سأستخدم بالتأكيد مفتاحًا رقميًا لا معنى له لجداول مثل الشخص والعنوان - ولكن ليس لجداول كل شئ, ، وهو الأمر الذي يبدو أن معظم الناس هنا يؤيدونه لسبب ما.

أنظر أيضا: جوابي على سؤال آخر

Answer 4

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

يجب استخدام المفتاح الأساسي للجدول لتحديد الصف بشكل فريد، وذلك بشكل أساسي لأغراض الربط.فكر في جدول الأشخاص:يمكن أن تتغير الأسماء، وليس من المؤكد أنها فريدة من نوعها.

فكر في الشركات:أنت شركة Merkin سعيدة تتعامل مع شركات أخرى في Merkia.أنت ذكي بما فيه الكفاية لعدم استخدام اسم الشركة كمفتاح أساسي، لذا يمكنك استخدام معرف الشركة الفريد الخاص بحكومة Merkia بالكامل المكون من 10 أحرف أبجدية رقمية.ثم قامت Merkia بتغيير معرفات الشركة لأنها اعتقدت أنها ستكون فكرة جيدة.لا بأس، يمكنك استخدام ميزة التحديثات المتتالية لمحرك قاعدة بياناتك، لإجراء تغيير لا ينبغي أن يشملك في المقام الأول.في وقت لاحق، يتوسع عملك، والآن تعمل مع شركة في فريدونيا.يصل معرف الشركة Freedonian إلى 16 حرفًا.تحتاج إلى تكبير المفتاح الأساسي لمعرف الشركة (أيضًا حقول المفتاح الخارجي في الطلبات والمشكلات وتحويلات الأموال وما إلى ذلك)، وإضافة حقل البلد في المفتاح الأساسي (أيضًا في المفاتيح الخارجية).أوه!حرب أهلية في فريدونيا، انقسمت إلى ثلاث دول.يجب تغيير اسم البلد الخاص بشريكك إلى الاسم الجديد؛تحديثات متتالية للإنقاذ.راجع للشغل، ما هو المفتاح الأساسي الخاص بك؟(البلد، معرف الشركة) أو (معرف الشركة، البلد)؟يساعد الأخير في الانضمام، بينما يتجنب الأول فهرسًا آخر (أو ربما الكثير، إذا كنت تريد تجميع طلباتك حسب البلد أيضًا).

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

Answer 5

لن يكون للمفتاح البديل سبب للتغيير أبدًا.لا أستطيع أن أقول الشيء نفسه عن المفاتيح الطبيعية.الأسماء الأخيرة، وعناوين البريد الإلكتروني، وأرقام ISBN - يمكن أن تتغير جميعها يومًا ما.

Answer 6

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

إليكم أسبابي:

1. عند استخدام المفاتيح الطبيعية، يتم تجميع الجداول بالطريقة التي يتم البحث بها غالبًا، مما يجعل الاستعلامات أسرع.

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

3. عند استخدام المفاتيح البديلة كمفتاح أساسي، يكون من غير الواضح ما هي المفاتيح الأساسية الطبيعية.عند التطوير، تريد معرفة مجموعة الأعمدة التي تجعل الجدول فريدًا.

4. في واحدة إلى العديد من سلاسل العلاقات، سلاسل المفاتيح المنطقية.على سبيل المثال، لدى المؤسسات العديد من الحسابات والحسابات لديها العديد من الفواتير.لذا فإن المفتاح المنطقي للمنظمة هو OrgName.المفتاح المنطقي للحسابات هو OrgName، AccountID.المفتاح المنطقي للفاتورة هو OrgName وAccountID وInvoiceNumber.

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

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

6. لدي ثلاثة كتب قواعد بيانات مختلفة.لا يظهر أي منهم باستخدام مفاتيح بديلة.

Answer 7

أريد أن أشارككم تجربتي في هذه الحرب التي لا نهاية لها: D حول المعضلة الرئيسية الطبيعية مقابل البديلة.اعتقد انه كلاهما تحتوي المفاتيح البديلة (المصطنعة التي يتم إنشاؤها تلقائيًا) والمفاتيح الطبيعية (المكونة من أعمدة (أعمدة) ذات معنى المجال) على الايجابيات و سلبيات.لذا، اعتمادًا على موقفك، قد يكون من الأفضل اختيار طريقة أو أخرى.

نظرًا لأن العديد من الأشخاص يقدمون المفاتيح البديلة باعتبارها الحل الأمثل تقريبًا والمفاتيح الطبيعية باعتبارها الطاعون، فسوف أركز على حجج وجهة النظر الأخرى:

عيوب المفاتيح البديلة

المفاتيح البديلة هي:

1. مصدر مشاكل الأداء:
   • يتم تنفيذها عادةً باستخدام أعمدة متزايدة تلقائيًا مما يعني:
     • رحلة ذهابًا وإيابًا إلى قاعدة البيانات في كل مرة تريد فيها الحصول على معرف جديد (أعلم أنه يمكن تحسين ذلك باستخدام التخزين المؤقت أو خوارزميات hilo على حد سواء ولكن لا تزال هذه الأساليب لها عيوبها الخاصة).
     • إذا كنت بحاجة يومًا ما إلى نقل بياناتك من مخطط إلى آخر (يحدث هذا بشكل منتظم في شركتي على الأقل)، فقد تواجه مشكلات تضارب المعرفات.ونعم، أعلم أنه يمكنك استخدام UUIDs ولكن تلك الأخيرة تتطلب 32 رقمًا سداسيًا عشريًا!(إذا كنت تهتم بحجم قاعدة البيانات فقد تكون هناك مشكلة).
     • إذا كنت تستخدم تسلسلًا واحدًا لجميع مفاتيحك البديلة، فسوف ينتهي بك الأمر - بالتأكيد - إلى التنافس على قاعدة البيانات الخاصة بك.
2. معرض للخطأ.يحتوي التسلسل على حد max_value لذلك - كمطور - عليك الانتباه إلى النقاط التالية:
   • يجب عليك تدوير التسلسل الخاص بك (عندما يتم الوصول إلى القيمة القصوى فإنه يعود إلى 1,2،...).
   • إذا كنت تستخدم التسلسل كترتيب (مع مرور الوقت) لبياناتك، فيجب عليك التعامل مع حالة التدوير (قد يكون العمود ذو المعرف 1 أحدث من الصف ذو القيمة القصوى للمعرف - 1).
   • تأكد من أن التعليمات البرمجية الخاصة بك (وحتى واجهات العميل الخاصة بك والتي لا ينبغي أن تحدث كما يفترض أن تكون معرفًا داخليًا) تدعم الأعداد الصحيحة 32b/64b التي استخدمتها لتخزين قيم التسلسل الخاصة بك.
3. أنها لا تضمن البيانات غير المكررة.يمكنك دائمًا الحصول على صفين بنفس قيم الأعمدة ولكن بقيمة تم إنشاؤها مختلفة.بالنسبة لي هذا هو ال مشكلة المفاتيح البديلة من وجهة نظر تصميم قاعدة البيانات.
4. المزيد في ويكيبيديا...

الخرافات حول المفاتيح الطبيعية

1. المفاتيح المركبة أقل كفاءة من المفاتيح البديلة.لا!يعتمد ذلك على محرك قاعدة البيانات المستخدم:
   • وحي
   • ماي إس كيو إل
2. المفاتيح الطبيعية غير موجودة في الحياة الواقعية.آسف لكنهم موجودون!في صناعة الطيران، على سبيل المثال، سيكون الصف التالي فريدًا دائمًا فيما يتعلق بمعطى معين المقرر الرحلة (شركة الطيران، تاريخ المغادرة، رقم الرحلة، اللاحقة التشغيلية).وبشكل أعم، عندما يتم ضمان أن تكون مجموعة من بيانات الأعمال فريدة من نوعها معيار فإن هذه المجموعة من البيانات تعتبر مرشحًا رئيسيًا طبيعيًا [جيدًا].
3. المفاتيح الطبيعية "تلوث مخطط" الجداول الفرعية.بالنسبة لي، هذا شعور أكثر من كونه مشكلة حقيقية.قد يكون وجود مفتاح أساسي مكون من 4 أعمدة يبلغ حجم كل منها 2 بايت أكثر كفاءة من عمود واحد يبلغ حجمه 11 بايت.علاوة على ذلك، يمكن استخدام الأعمدة الأربعة للاستعلام عن الجدول الفرعي مباشرة (باستخدام الأعمدة الأربعة في عبارة أين) دون الانضمام إلى الجدول الأصلي.

خاتمة

استخدم المفاتيح الطبيعية عندما يكون ذلك مناسبًا واستخدم المفاتيح البديلة عندما يكون من الأفضل استخدامها.

نأمل أن يكون هذا ساعد شخص ما!

Answer 8

استخدم دائمًا مفتاحًا ليس له أي معنى تجاري.إنها مجرد ممارسة جيدة.

يحرر:حاولت أن أجد رابطًا له عبر الإنترنت، لكني لم أستطع.ومع ذلك، في "أنماط البنية المؤسسية" [فاولر] يحتوي على تفسير جيد لسبب عدم استخدام أي شيء آخر غير المفتاح دون أي معنى سوى كونه مفتاحًا.ويتلخص الأمر في أنه ينبغي أن يكون لها وظيفة واحدة ووظيفة واحدة فقط.

Answer 9

تعد المفاتيح البديلة مفيدة جدًا إذا كنت تخطط لاستخدام أداة ORM للتعامل مع/إنشاء فئات البيانات الخاصة بك.بينما يمكنك استخدام المفاتيح المركبة مع بعض مصممي الخرائط الأكثر تقدمًا (اقرأ:السبات)، فإنه يضيف بعض التعقيد إلى التعليمات البرمجية الخاصة بك.

(وبطبيعة الحال، سوف يجادل المتشددون في قواعد البيانات بأن حتى فكرة وجود مفتاح بديل هي فكرة مقيتة.)

أنا معجب باستخدام uids للمفاتيح البديلة عندما يكون ذلك مناسبًا.الفوز الرئيسي معهم هو أنك تعرف المفتاح مقدمًا، على سبيل المثال.يمكنك إنشاء مثيل لفئة مع معرف تم تعيينه بالفعل وضمان أن يكون فريدًا بينما، على سبيل المثال، باستخدام مفتاح عدد صحيح ستحتاج إلى الإعداد الافتراضي إلى 0 أو -1 والتحديث إلى قيمة مناسبة عند الحفظ/التحديث.

UIDs لها عقوبات من حيث سرعة البحث والانضمام على الرغم من أن ذلك يعتمد على التطبيق المعني فيما يتعلق بما إذا كانت مرغوبة أم لا.

Answer 10

يعد استخدام مفتاح بديل أفضل في رأيي حيث لا توجد فرصة لتغييره.تقريبًا أي شيء يمكنني التفكير فيه والذي قد تستخدمه كمفتاح طبيعي يمكن أن يتغير (إخلاء المسؤولية:ليس صحيحا دائما، ولكن عادة).

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

Answer 11

استخدم دائمًا عمودًا واحدًا ومفتاحًا بديلًا إذا كان ذلك ممكنًا.وهذا يجعل عمليات الانضمام وكذلك عمليات الإدراج/التحديثات/الحذف أكثر نظافة لأنك مسؤول فقط عن تتبع جزء واحد من المعلومات للحفاظ على السجل.

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

يمكن أن يتغير منطق الأعمال/المفاتيح الطبيعية، لكن المفتاح المادي للجدول يجب ألا يتغير أبدًا.

Answer 12

في سيناريو مستودع البيانات، أعتقد أنه من الأفضل اتباع مسار المفتاح البديل.سببان:

• أنت مستقل عن النظام المصدر، والتغييرات هناك - مثل تغيير نوع البيانات - لن تؤثر عليك.
• سيحتاج DW الخاص بك إلى مساحة فعلية أقل نظرًا لأنك ستستخدم فقط أنواع البيانات الصحيحة لمفاتيحك البديلة.كما ستعمل الفهارس الخاصة بك بشكل أفضل.

Answer 13

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

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

Answer 14

للتذكير، ليس من الممارسات الجيدة وضع مؤشرات مجمعة على مفاتيح بديلة عشوائية، على سبيل المثال.المعرفات الفريدة العمومية (GUIDs) التي تقرأ XY8D7-DFD8S، حيث أن SQL Server ليس لديه القدرة على فرز هذه البيانات فعليًا.يجب عليك بدلاً من ذلك وضع مؤشرات فريدة على هذه البيانات، على الرغم من أنه قد يكون من المفيد أيضًا تشغيل ملف تعريف SQL لعمليات الجدول الرئيسية ثم وضع هذه البيانات في Database Engine Tuning Advisor.

شاهد الموضوع @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

Answer 15

حالة 1: الجدول الخاص بك هو أ جدول البحث مع أقل من 50 نوعا (إدراج)

يستخدم مفاتيح الأعمال/الطبيعية.على سبيل المثال:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

الحالة 2: الجدول الخاص بك هو أ جدول يحتوي على آلاف الإدخالات

يستخدم مفاتيح بديلة/الزيادة التلقائية.على سبيل المثال:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

في الحالة الأولى:

• يمكنك تحديد كافة المبرمجين في الجدول PEOPLE دون استخدام الانضمام مع الجدول JOB، ولكن فقط باستخدام:"اختر * من الأشخاص الذين لديهم JOBCODE = 'PRG'"

وفي الحالة الثانية:

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

Answer 16

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

Answer 17

الحصان للدورات.لتوضيح تحيّزي؛أنا مطور أولاً، لذا فأنا مهتم بشكل أساسي بمنح المستخدمين تطبيقًا فعالاً.

لقد عملت على أنظمة ذات مفاتيح طبيعية، واضطررت إلى قضاء الكثير من الوقت للتأكد من أن تغييرات القيمة ستسري.

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

معظم مطوري PL/SQL التقليديين الذين عملت معهم لم يعجبهم المفاتيح البديلة بسبب عدد الجداول لكل صلة، لكن قواعد بيانات الاختبار والإنتاج الخاصة بنا لم تثير أي جهد أبدًا؛لم تؤثر الصلات الإضافية على أداء التطبيق.مع لهجات قاعدة البيانات التي لا تدعم عبارات مثل "X inside join Y on X.a = Y.b"، أو المطورين الذين لا يستخدمون بناء الجملة هذا، فإن الصلات الإضافية للمفاتيح البديلة تجعل قراءة الاستعلامات أكثر صعوبة، وتستغرق وقتًا أطول في الكتابة والطباعة. يفحص:راجع مشاركة @Tony Andrews.ولكن إذا كنت تستخدم ORM أو أي إطار عمل آخر لإنشاء SQL فلن تلاحظ ذلك.الكتابة باللمس تخفف أيضًا.

Answer 18

ربما لا يتعلق الأمر بهذا الموضوع تمامًا، لكن الصداع الذي أعاني منه هو التعامل مع المفاتيح البديلة.تقوم Oracle Analytics التي تم تسليمها مسبقًا بإنشاء SKs تم إنشاؤها تلقائيًا على جميع جداول الأبعاد الخاصة بها في المستودع، كما تقوم أيضًا بتخزين تلك الموجودة في الحقائق.لذا، في أي وقت تحتاج (الأبعاد) إلى إعادة تحميلها عند إضافة أعمدة جديدة أو يلزم ملؤها لجميع العناصر في البعد، فإن SKs المعينة أثناء التحديث تجعل SKs غير متزامنة مع القيم الأصلية المخزنة على الحقيقة، مما يفرض إعادة تحميل كاملة لجميع جداول الحقائق التي تنضم إليها.أفضل أنه حتى لو كان SK رقمًا لا معنى له، فسيكون هناك طريقة ما بحيث لا يمكن تغييره بالنسبة للسجلات الأصلية/القديمة.كما يعلم الكثيرون، نادرًا ما يخدم التصميم الجاهز احتياجات المؤسسة، وعلينا أن نقوم بالتخصيص باستمرار.لدينا الآن ما يعادل 3 سنوات من البيانات في مستودعاتنا، وعمليات إعادة التحميل الكاملة من أنظمة Oracle المالية كبيرة جدًا.لذلك، في حالتي، لا يتم إنشاؤها من إدخال البيانات، ولكن تتم إضافتها في المستودع للمساعدة في إعداد التقارير عن الأداء.أتفهم ذلك، لكن أسلوبنا يتغير، وهو كابوس.

Answer 19

في حالة قاعدة البيانات الخاصة بالنقطة الزمنية، من الأفضل أن يكون لديك مجموعة من المفاتيح البديلة والطبيعية.على سبيل المثالتحتاج إلى تتبع معلومات العضو للنادي.بعض صفات العضو لا تتغير أبدًا.على سبيل المثال، تاريخ الميلاد ولكن الاسم يمكن أن يتغير.لذا قم بإنشاء جدول عضو باستخدام مفتاح بديل member_id واحصل على عمود لـ DOB.قم بإنشاء جدول آخر يسمى اسم الشخص ويحتوي على أعمدة لـ member_id و member_fname و member_lname و date_updated.في هذا الجدول، سيكون المفتاح الطبيعي هو member_id + date_updated.