الفريق العربي للبرمجةأرشيف المنتديات · 2000 – 2023
نسخة أرشيفية للقراءة فقط — التسجيل والمشاركة مغلقان، والمحتوى محفوظ كما كان.

الحل الأمثل في استخدام Composite Keys

بدأه HelloWorld في 22 أكتوبر 2010 · 2 رد · 2,489 مشاهدة · في قواعد بيانات Microsoft SQL Server
مشاركة: واتساب X فيسبوك تيليجرام
#1 صاحب الموضوع

السلام عليكم ورحمة الله وبركاته...

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

مثال على هذه المشكلة، ببساطة أن لدينا قاعدة بيانات تحتوي على الكثير من الجداول وأغلب هذه الجداول مرتبط بجدول رئيسي يحتوي على أكثر من مفتاح، مثال على ذلك فلنتفترض أن لدينا نظام إدارة المدارس فيه خاصية تعدد المدارس(أكثر من مدرسة) ، ومعلومات المدارس تخزن في جدول خاص بها اسمه مثلا SchoolsTable ويحتوي هذا الجدول على مفتاح رئيسي SchoolID، وهذا المفتاح يستخدم في أغلب جداول النظام مع المفتاح الرئيسي لكل جدول، وهو في الحقيقة يمثل مفتاح مركب Composite Key (المفتاح المركب: هو وجود أكثر من مفتاح رئيسي في نفس الجدول) لا يمكن أن يتكرر بناء على التحليل المنطقي، مثال على ذلك لو أن لدينا جدول StudentsTable ويحتوي على StudentID وهو مفتاح حقيقي بالاضافة إلى SchoolID ، بمعنى رقم الطالب يمكن أن يتكرر في مدرسة أخرى ولا يمكن أن يتكرر في نفس المدرسة فما هو الحل بالنسبة إلى SchoolID ولدينا الكثير من الجداول التي تعتمد هذا المنطق، هل الحل الأمثل هو:

1) جعل StudentID وال SchoolID كمفتاح مركب في جدول StudentTable وكل الجداول الأخرى (افترضوا باأن النظام يحتوي على 100 جدول) ، أليس في ذلك صعوبة وتعقيد بالغ لاستخدام المفاتيح المركبة بهذا الشكل المكثف فضلا عن أن كل مفتاح رئيسي إضافي سوف يكون له Index خاص به مما قد يؤثر على أداء قاعدة البيانات ككل.

2) عمل جدول جديد يحتوي على كلا من StudentID و SchoolID ويتم إضافة Unique Constraint لهما، وإضافة مفتاح آخر باسم StudentSchoolID يكون هو المفتاح الرئيسي ويتم استخدامه في كافة جداول قاعدة البيانات. والصعوبة في هذا الخيار هو أن عملية الاستعلام عن المعلومات SQL Queries سوف تكون معقدة من حيث أنها تحتاج في كل مرة لعملية الربط JOIN مع هذا الجدول، مثال للتوضيح على ذلك، لنفترض أن لدينا جدول يمثل نشاطات الطلبة StudentActivity في الحالة المعتادة سوف نستخدم الاستعلام التالي:

Select * From StudentActivity Where StudentID = '20105003' And SchoolID = 1

أما بالطريقة التي ذكرتها فتصوروا طريقة كتابة الاستعلام!!

3) عمل Unique Constraint لكلا من SchoolID و StudentID في الجداول الأخرى مثل StudentActivity بدون إضافة مفتاح مركب أو تعقيد الاستعلامات حسب الخيار الثاني.

4) عمل قاعدة بيانات لكل مدرسة: هذا خيار آخر ولكن الصعوبة فيه تكمن في إدارة كل قاعدة بيانات على حدة بالاضافة إلى صعوبة عمل الاستعلامات لأكثر من مدرسة في نفس الوقت.

نفس المثال الذي طرحته على المدارس يمكن تطبيقه على (تعدد الشركات) في نظام المحاسبة كذلك.

برأيكم ما هو الحل الأمثل؟ نظريا وعمليا؟ من واقع معرفتكم وخبرتكم؟

أفيدونا أفادكم الله.

#2

مرحباً،

لستُ أدري إن كان الموضوع الذي طرحته معقدا شيئا ما، أم أنا الذي عقدته :lol: ، هل لدى أحدكم فكرة عما أتحدث؟

#3

السلام عليكم.

الحل الأول لا أفضل التعامل به كونه أيضاً يخلق مشاكل في واجهات البرنامج ( مثلاً عند محتولة استخدام ComboBox و تحديد ValueMember حيث لا يمكن استخدام مفتاح مركب :wacko: )

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

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

1

مواضيع مشابهة