هل المفاتيح الخارجية ضرورية حقًا في تصميم قاعدة البيانات؟
https://stackoverflow.com/questions/18717
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
بقدر ما أعرف، يتم استخدام المفاتيح الخارجية (FK) لمساعدة المبرمج على معالجة البيانات بالطريقة الصحيحة.لنفترض أن أحد المبرمجين يقوم بذلك بالفعل بالطريقة الصحيحة، فهل نحتاج حقًا إلى مفهوم المفاتيح الخارجية؟
هل هناك أي استخدامات أخرى للمفاتيح الخارجية؟نسيت شيئا ما هنا؟
المحلول
تساعد المفاتيح الخارجية في فرض التكامل المرجعي على مستوى البيانات.كما أنها تعمل أيضًا على تحسين الأداء نظرًا لأنه تتم فهرستها عادةً بشكل افتراضي.
نصائح أخرى
يمكن أن تساعد المفاتيح الخارجية أيضًا المبرمج في كتابة تعليمات برمجية أقل باستخدام أشياء مثل ON DELETE CASCADE.وهذا يعني أنه إذا كان لديك جدول يحتوي على مستخدمين وآخر يحتوي على أوامر أو شيء من هذا القبيل، فإن حذف مستخدم قد يؤدي تلقائيًا إلى حذف جميع الطلبات التي تشير إلى هذا المستخدم.
لا أستطيع أن أتخيل تصميم قاعدة بيانات بدون مفاتيح خارجية.وبدونها، في النهاية لا بد أن ترتكب خطأ وتفسد سلامة بياناتك.
هم ليسوا مطلوب, بالمعنى الدقيق للكلمة، ولكن الفوائد ضخمة.
أنا متأكد من ذلك إلى حد ما com.FogBugz ليس لديها قيود المفتاح الخارجي في قاعدة البيانات.سأكون مهتمًا بسماع كيف برامج الضباب كريك يقوم الفريق ببناء الكود الخاص به لضمان عدم حدوث أي تناقض أبدًا.
يشبه مخطط قاعدة البيانات بدون قيود FK القيادة بدون حزام الأمان.
ذات يوم، سوف تندم على ذلك.يعد عدم قضاء هذا الوقت الإضافي القليل في أساسيات التصميم وسلامة البيانات طريقة مؤكدة لضمان حدوث الصداع لاحقًا.
هل ستقبل التعليمات البرمجية في تطبيقك التي كانت قذرة إلى هذا الحد؟أدى ذلك إلى الوصول مباشرة إلى كائنات الأعضاء وتعديل هياكل البيانات مباشرة.
لماذا تعتقد أن هذا قد أصبح صعبا و حتى غير مقبول ضمن اللغات الحديثة؟
نعم.
- يبقيك صادقا
- إنهم يحافظون على صدق المطورين الجدد
- يمكنك ان تفعل
ON DELETE CASCADE - إنها تساعدك على إنشاء مخططات جميلة تشرح ذاتيًا الروابط بين الجداول
أنا شخصياً أؤيد المفاتيح الخارجية لأنها تضفي الطابع الرسمي على العلاقة بين الجداول.أدرك أن سؤالك يفترض مسبقًا أن المبرمج لا يقدم بيانات من شأنها أن تنتهك التكامل المرجعي، لكنني رأيت الكثير من الحالات التي يتم فيها انتهاك التكامل المرجعي للبيانات، على الرغم من النوايا الحسنة!
تم إنفاق الكثير من الوقت على قيود المفاتيح الخارجية السابقة (المعروفة أيضًا باسم التكامل المرجعي التعريفي أو DRI) في تنفيذ هذه العلاقات باستخدام المشغلات.إن حقيقة قدرتنا على إضفاء الطابع الرسمي على العلاقة من خلال قيد تصريحي هي حقيقة قوية للغاية.
@John - قد تقوم قواعد البيانات الأخرى تلقائيًا بإنشاء فهارس للمفاتيح الخارجية، لكن SQL Server لا يقوم بذلك.في SQL Server، تعتبر علاقات المفاتيح الخارجية مجرد قيود.يجب عليك تحديد الفهرس الخاص بك على المفاتيح الخارجية بشكل منفصل (وهو ما يمكن أن يكون مفيدًا.)
يحرر:أود أن أضيف، IMO، أن استخدام المفاتيح الخارجية لدعم ON DELETE أو ON UPDATE CASCADE ليس بالضرورة أمرًا جيدًا.من الناحية العملية، وجدت أن التتالي عند الحذف يجب أن يُنظر إليه بعناية بناءً على العلاقة بين البيانات - على سبيل المثال.هل لديك أحد الوالدين والطفل الطبيعي حيث قد يكون هذا جيدًا أم أن الجدول المرتبط عبارة عن مجموعة من قيم البحث.يشير استخدام التحديثات المتتالية إلى أنك تسمح بتعديل المفتاح الأساسي لجدول واحد.في هذه الحالة، لدي خلاف فلسفي عام في أن المفتاح الأساسي للجدول لا ينبغي أن يتغير.يجب أن تكون المفاتيح ثابتة بطبيعتها.
لنفترض أن أحد المبرمجين يقوم بذلك بالفعل بالطريقة الصحيحة بالفعل
يبدو لي أن تقديم مثل هذا الافتراض فكرة سيئة للغاية؛في البرمجيات العامة هو عربات التي تجرها الدواب بشكل هائل.
وهذه هي النقطة، حقا.لا يستطيع المطورون تصحيح الأمور، لذا فإن التأكد من عدم امتلاء قاعدة البيانات ببيانات سيئة هو أمر جيد.
على الرغم من أنه في عالم مثالي، فإن الصلات الطبيعية ستستخدم العلاقات (أي.قيود FK) بدلاً من مطابقة أسماء الأعمدة.وهذا من شأنه أن يجعل FKs أكثر فائدة.
بدون مفتاح خارجي كيف يمكنك معرفة أن سجلين في جداول مختلفة مرتبطان؟
أعتقد أن ما تشير إليه هو التكامل المرجعي، حيث لا يُسمح بإنشاء سجل فرعي بدون سجل أصل موجود وما إلى ذلك.تُعرف هذه غالبًا باسم قيود المفاتيح الخارجية - ولكن لا ينبغي الخلط بينها وبين وجود المفاتيح الخارجية في المقام الأول.
هل هناك فائدة لعدم وجود مفاتيح خارجية؟ما لم تكن تستخدم قاعدة بيانات سيئة، فلن يكون إعداد FKs بهذه الصعوبة.فلماذا لديك سياسة تجنبهم؟إن وجود اصطلاح تسمية ينص على أن العمود يشير إلى عمود آخر هو شيء واحد، وهو أمر آخر أن تعرف أن قاعدة البيانات تتحقق بالفعل من هذه العلاقة نيابةً عنك.
أفترض أنك تتحدث عنه قيود المفتاح الخارجي التي تفرضها قاعدة البيانات.من المحتمل أنك تستخدم المفاتيح الخارجية بالفعل، لكنك لم تخبر قاعدة البيانات عنها.
لنفترض أن المبرمج يقوم بذلك بالفعل بالطريقة الصحيحة بالفعل ، فهل نحتاج حقًا إلى مفهوم المفاتيح الأجنبية؟
من الناحية النظرية، لا.ومع ذلك، لم يكن هناك أي برنامج بدون أخطاء.
عادةً لا تكون الأخطاء الموجودة في كود التطبيق بهذه الخطورة - يمكنك تحديد الخطأ وإصلاحه، وبعد ذلك يعمل التطبيق بسلاسة مرة أخرى.ولكن إذا كان هناك خطأ يسمح للبيانات المتقطعة بالدخول إلى قاعدة البيانات، فأنت عالق في هذا الأمر!من الصعب جدًا استرداد البيانات التالفة في قاعدة البيانات.
ضع في اعتبارك ما إذا كان هناك خطأ خفي com.FogBugz السماح بكتابة مفتاح خارجي تالف في قاعدة البيانات.قد يكون من السهل إصلاح الخلل وإرسال الإصلاح بسرعة إلى العملاء في إصدار إصلاح الخلل.ومع ذلك، كيف يمكن إصلاح البيانات الفاسدة في العشرات من قواعد البيانات؟ صحيح قد ينقطع الكود الآن فجأة لأن الافتراضات المتعلقة بسلامة المفاتيح الخارجية لم تعد قائمة.
في تطبيقات الويب، عادةً ما يكون لديك برنامج واحد فقط يتحدث إلى قاعدة البيانات، لذلك لا يوجد سوى مكان واحد حيث يمكن للأخطاء أن تفسد البيانات.في تطبيق المؤسسة، قد يكون هناك العديد من التطبيقات المستقلة التي تتحدث إلى نفس قاعدة البيانات (ناهيك عن الأشخاص الذين يعملون مباشرة مع هيكل قاعدة البيانات).لا توجد طريقة للتأكد من أن جميع التطبيقات تتبع نفس الافتراضات دون أخطاء، دائمًا وأبدًا.
إذا تم ترميز القيود في قاعدة البيانات، فإن أسوأ ما يمكن أن يحدث مع الأخطاء هو أن تظهر للمستخدم رسالة خطأ قبيحة حول بعض الأخطاء SQL القيد غير راض.هذا هو كثيراً من الأفضل السماح للبيانات المتقطعة بالدخول إلى قاعدة بيانات مؤسستك، حيث سيؤدي ذلك بدوره إلى تعطيل جميع تطبيقاتك أو يؤدي فقط إلى جميع أنواع المخرجات الخاطئة أو المضللة.
تعمل قيود المفاتيح الخارجية أيضًا على تحسين الأداء لأنها تتم فهرستها افتراضيًا.لا أستطيع التفكير في أي سبب لا لاستخدام قيود المفتاح الخارجي.
تعد FKs مهمة جدًا ويجب أن تكون موجودة دائمًا في مخططك، إلا إذا كنت موقع ئي باي.
أظن شيء واحد في مرحلة ما يجب أن يكون مسؤولاً عن ضمان علاقات صحيحة.
على سبيل المثال، روبي على القضبان لا يستخدم المفاتيح الخارجية، ولكنه يتحقق من صحة جميع العلاقات نفسها.إذا كنت لا تستطيع الوصول إلى قاعدة بياناتك إلا من خلال تطبيق Ruby on Rails، فلا بأس بذلك.
ومع ذلك، إذا كان لديك عملاء آخرين يكتبون إلى قاعدة البيانات، فبدون المفاتيح الخارجية، يحتاجون إلى تنفيذ التحقق الخاص بهم.لديك بعد ذلك نسختان من رمز التحقق، والتي على الأرجح مختلفة، والتي يجب على أي مبرمج أن يعرف أنها خطيئة كبرى.
عند هذه النقطة، تكون المفاتيح الخارجية ضرورية حقًا، لأنها تسمح لك بنقل المسؤولية إلى نقطة واحدة مرة أخرى.
تسمح المفاتيح الخارجية لأي شخص لم ير قاعدة البيانات الخاصة بك من قبل بتحديد العلاقة بين الجداول.
قد يكون كل شيء على ما يرام الآن، ولكن فكر فيما سيحدث عندما يغادر المبرمج لديك ويتولى شخص آخر المهمة.
ستسمح لهم المفاتيح الخارجية بفهم بنية قاعدة البيانات دون الحاجة إلى البحث في آلاف الأسطر من التعليمات البرمجية.
بقدر ما أعرف، يتم استخدام المفاتيح الخارجية لمساعدة المبرمج على التعامل مع البيانات بالطريقة الصحيحة.
تسمح FKs لـ DBA بحماية سلامة البيانات من تحسس المستخدمين عند المبرمج فشل للقيام بذلك، وأحيانًا للحماية من تخبط المبرمجين.
لنفترض أن أحد المبرمجين يقوم بذلك بالفعل بالطريقة الصحيحة، فهل نحتاج حقًا إلى مفهوم المفاتيح الخارجية؟
المبرمجون بشر وغير معصومين من الخطأ.FKs هي تصريحي مما يجعل من الصعب حلها.
هل هناك أي استخدامات أخرى للمفاتيح الخارجية؟نسيت شيئا ما هنا؟
على الرغم من أن هذا ليس سبب إنشائها، إلا أن FKs توفر تلميحات قوية وموثوقة لأدوات التخطيط ولمنشئي الاستعلامات.يتم تمرير هذا إلى المستخدمين النهائيين، الذين يحتاجون بشدة إلى تلميحات موثوقة وقوية.
إنها ليست ضرورية تمامًا، مثلما أن أحزمة الأمان ليست ضرورية تمامًا.لكن يمكنهم حقًا إنقاذك من القيام بشيء غبي من شأنه أن يفسد قاعدة بياناتك.
من الأفضل تصحيح خطأ قيد FK بدلاً من إعادة إنشاء عملية الحذف التي أدت إلى تعطيل تطبيقك.
إنها مهمة، لأن التطبيق الخاص بك ليس الطريقة الوحيدة التي يمكن من خلالها معالجة البيانات في قاعدة البيانات.قد يتعامل تطبيقك مع التكامل المرجعي بأمانة كما يريد، ولكن كل ما يتطلبه الأمر هو شخص واحد يتمتع بالامتيازات المناسبة ليأتي ويصدر أمر إدراج أو حذف أو تحديث على مستوى قاعدة البيانات، ويتم تجاوز كل إجراءات فرض التكامل المرجعي للتطبيق.إن وضع قيود FK على مستوى قاعدة البيانات يعني أنه، باستثناء هذا bozo الذي يختار تعطيل قيد FK قبل إصدار أمره، فإن قيد FK سوف يتسبب في فشل عبارة إدراج/تحديث/حذف سيئة مع انتهاك التكامل المرجعي.
أفكر في الأمر من حيث التكلفة / المنفعة ...في ماي إس كيو إل, ، إضافة القيد هو سطر إضافي واحد من دي دي إل.إنها مجرد حفنة من الكلمات الرئيسية وبضع ثوانٍ من التفكير.هذه هي "التكلفة" الوحيدة في رأيي.
الأدوات تحب المفاتيح الخارجية.تمنع المفاتيح الخارجية البيانات السيئة (أي الصفوف المعزولة) التي قد لا تؤثر على منطق العمل أو وظائفه، وبالتالي تمر دون أن يلاحظها أحد وتتراكم.كما أنه يمنع المطورين الذين ليسوا على دراية بالمخطط من تنفيذ أجزاء كاملة من العمل دون أن يدركوا أنهم يفتقدون العلاقة.ربما يكون كل شيء رائعًا في نطاق تطبيقك الحالي، ولكن إذا فاتك شيء ما وأضيف شيء غير متوقع في يوم من الأيام (فكر في إعداد تقارير رائعة)، فقد تكون في مكان يتعين عليك فيه تنظيف البيانات السيئة التي تراكمت منذ البداية يدويًا للمخطط دون إجراء فحص مفروض لقاعدة البيانات.
إن الوقت القليل الذي تستغرقه لتدوين ما يدور في رأسك بالفعل عندما تقوم بتجميع الأشياء معًا يمكن أن يوفر عليك أو على أي شخص آخر مجموعة من الحزن لأشهر أو سنوات على الطريق.
السؤال:
هل هناك أي استخدامات أخرى للمفاتيح الأجنبية؟نسيت شيئا ما هنا؟
انها محملة قليلا.أدخل التعليقات أو المسافة البادئة أو تسمية المتغيرات بدلاً من "المفاتيح الخارجية"...إذا كنت تفهم بالفعل الشيء المعني تمامًا، فهذا "لا فائدة منه" بالنسبة لك.
تخفيض الانتروبيا.تقليل احتمالية حدوث سيناريوهات فوضوية في قاعدة البيانات.إننا نواجه وقتًا عصيبًا حيث أننا نأخذ في الاعتبار جميع الاحتمالات، لذلك، في رأيي، يعد تقليل الإنتروبيا أمرًا أساسيًا لصيانة أي نظام.
عندما نضع افتراضا على سبيل المثال:كل أمر له عميل يجب تنفيذ الافتراض من خلاله شئ ما.في قواعد البيانات أن "الشيء" هو مفاتيح خارجية.
أعتقد أن هذا يستحق المقايضة في سرعة التطوير.بالتأكيد، يمكنك البرمجة بشكل أسرع مع إيقاف تشغيلها، وربما يكون هذا هو السبب وراء عدم استخدام بعض الأشخاص لها.أنا شخصياً قتلت عدة ساعات مع السبات وبعض قيود المفاتيح الخارجية التي تغضب عندما أقوم ببعض العمليات.ومع ذلك، فأنا أعرف ما هي المشكلة، لذا فهي مشكلة أقل.أنا أستخدم الأدوات العادية وهناك موارد لمساعدتي في حل هذه المشكلة، وربما حتى أشخاص للمساعدة!
البديل هو السماح لخلل ما بالتسلل إلى النظام (وبمرور الوقت الكافي، سيفعل ذلك) عندما لا يتم تعيين مفتاح خارجي وتصبح بياناتك غير متسقة.بعد ذلك، تحصل على تقرير خطأ غير عادي، قم بالتحقيق فيه و"أوه".قاعدة البيانات مشدودة.الآن كم من الوقت سيستغرق إصلاح ذلك؟
يمكنك عرض المفاتيح الخارجية كقيد،
- المساعدة في الحفاظ على سلامة البيانات
- إظهار كيفية ارتباط البيانات ببعضها البعض (مما يمكن أن يساعد في فرض منطق العمل وقواعده)
- إذا تم استخدامه بشكل صحيح، يمكن أن يساعد في زيادة كفاءة جلب البيانات من الجداول.
نحن لا نستخدم حاليًا المفاتيح الخارجية.وفي الغالب لا نأسف لذلك.
ومع ذلك، فمن المحتمل أن نبدأ في استخدامها بشكل أكبر في المستقبل القريب لعدة أسباب، وكلاهما لأسباب مماثلة:
رسم تخطيطي.من الأسهل جدًا إنتاج رسم تخطيطي لقاعدة البيانات إذا كانت هناك علاقات مفاتيح خارجية مستخدمة بشكل صحيح.
دعم الأداة.من الأسهل كثيرًا إنشاء نماذج البيانات باستخدام فيجوال ستوديو 2008 التي يمكن استخدامها ل LINQ إلى SQL إذا كانت هناك علاقات مفاتيح خارجية مناسبة.
لذا أعتقد أن وجهة نظري هي أننا وجدنا أنه إذا كنا نقوم بالكثير من أعمال SQL اليدوية (إنشاء استعلام، تشغيل استعلام، بلاهبلاهبلاه) فإن المفاتيح الخارجية ليست ضرورية بالضرورة.بمجرد البدء في استخدام الأدوات، تصبح أكثر فائدة.
أفضل ما في قيود المفاتيح الخارجية (والقيود بشكل عام، حقًا) هو أنه يمكنك الاعتماد عليها عند كتابة استفساراتك.يمكن أن تصبح الكثير من الاستعلامات أكثر تعقيدًا إذا لم تتمكن من الاعتماد على نموذج البيانات الذي يحمل كلمة "صحيح".
في الكود، سنحصل بشكل عام على استثناء في مكان ما - ولكن في الداخل SQL, ، سنحصل بشكل عام على الإجابات "الخاطئة".
نظريا، خادم قاعدة البيانات يمكن استخدام القيود كجزء من خطة الاستعلام - ولكن باستثناء قيود التحقق من التقسيم، لا أستطيع أن أقول إنني شهدت ذلك بالفعل.
لم تكن المفاتيح الخارجية صريحة أبدًا (جدول مراجع المفاتيح الأجنبية (العمود)) المُعلن عنها في المشاريع (تطبيقات الأعمال ومواقع الشبكات الاجتماعية) التي عملت عليها.
ولكن كان هناك دائمًا نوع من الاصطلاح لتسمية الأعمدة التي كانت عبارة عن مفاتيح خارجية.
انها مثل مع تطبيع قاعدة البيانات - عليك أن تعرف ماذا تفعل وما هي نتائج ذلك (الأداء بشكل أساسي).
أنا على دراية بمزايا المفاتيح الخارجية (تكامل البيانات، وفهرس عمود المفتاح الخارجي، والأدوات المدركة لمخطط قاعدة البيانات)، ولكني أيضًا أخشى استخدام المفاتيح الخارجية كقاعدة عامة.
كما يمكن لمحركات قواعد البيانات المختلفة أن تخدم المفاتيح الخارجية بطريقة مختلفة، مما قد يؤدي إلى أخطاء دقيقة أثناء الترحيل.
تعد إزالة جميع الطلبات والفواتير الخاصة بالعميل المحذوف باستخدام ON DELETE CASCADE مثالًا مثاليًا لمخطط قاعدة البيانات ذو المظهر الجميل، ولكن المصمم بشكل خاطئ.
نعم.يعمل خيار ON DELETE [RESTRICT|CASCADE] على منع المطورين من تقسيم البيانات، مما يحافظ على نظافة البيانات.لقد انضممت مؤخرًا إلى فريق من مطوري Rails الذين لم يركزوا على قيود قاعدة البيانات مثل المفاتيح الخارجية.
ولحسن الحظ، وجدت هذه: http://www.redhillonrails.org/foreign_key_associations.html - تقوم المكونات الإضافية لـ RedHill on Ruby on Rails بإنشاء مفاتيح خارجية باستخدام اتفاقية على التكوين أسلوب.الهجرة مع معرف المنتج سيتم إنشاء مفتاح خارجي ل بطاقة تعريف في ال منتجات طاولة.
تحقق من المكونات الإضافية الرائعة الأخرى على التل الأحمر, ، بما في ذلك الهجرات المغلفة بالمعاملات.
