اعتبارات الأداء للمشغلات مقابل القيود

https://stackoverflow.com/questions/148129

02-07-2019
|

سؤال

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

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

المحلول

القيود بأيديهم!

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

لشرح نفسي بشكل أفضل من خلال القياس:الطريقة الصحيحة لكتابة استعلام SQL هي تحديد "ما تريد" بدلاً من "كيفية الحصول عليه" - اسمح لنظام RDBMS بمعرفة أفضل طريقة للقيام بذلك نيابةً عنك.وينطبق الشيء نفسه هنا:إذا كنت تستخدم المشغلات، عليك أن تضع في اعتبارك أشياء مختلفة مثل ترتيب التنفيذ، والتتالي، وما إلى ذلك...اسمح لـ SQL بالقيام بذلك نيابةً عنك مع القيود إن أمكن.

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

نصائح أخرى

افضل تمرين:إذا كان بإمكانك فعل ذلك مع وجود قيد، فاستخدم القيد.

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

في بعض الأحيان يكون من الضروري استخدام مشغل لفرض قيد "معقد" مثل حالة الرغبة في فرض واحد فقط من حقلي المفتاح الخارجي في الجدول (لقد رأيت هذا الموقف في عدد قليل من نماذج المجال).

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

يمكن أن تؤدي المشغلات إلى مشكلة في الأداء.في نفس الوقت تقريبًا، أصبحوا أيضًا كابوسًا للصيانة.لا يمكنك معرفة ما يحدث و (مكافأة!) يتصرف التطبيق بشكل متقطع مع مشاكل البيانات "الزائفة".[حقًا، إنها تثير المشكلات.]

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

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

"كيف يمكنني الحصول على تأكيد مطلق بأن الجميع يستخدمون نموذج البيانات بشكل صحيح؟"

تقنيتان (ونصف).

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

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

المشغلات هي حطام قطار ينتظر حدوثه.القيود ليست كذلك.

بالإضافة إلى الأسباب الأخرى لاستخدام القيود، يمكن لمُحسِّن Oracle استخدام القيود لصالحه.

على سبيل المثال، إذا كان لديك قول مقيد (Amount >= 0) ومن ثم يمكنك الاستعلام مع WHERE (Amount = -5) تعرف Oracle على الفور أنه لا توجد صفوف متطابقة.

القيود والمشغلات مخصصة لشيئين مختلفين.يتم استخدام القيود ل تقييد المجال (المدخلات الصالحة) لبياناتك.على سبيل المثال، سيتم تخزين رقم الضمان الاجتماعي (SSN) كحرف (9)، ولكن مع قيد [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [ 0-9] [0-9] [0-9] (جميعها رقمية).

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

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

بشكل عام، أفضّل القيود وسيكتشف الكود الخاص بي أخطاء خادم SQL ويقدم شيئًا أكثر ملاءمة للمستخدم.

@onedaywhen

يمكن أن يكون لديك استعلام كقيد في SQL Server، عليك فقط أن تكون قادرًا على ملاءمته في دالة عددية:http://www.eggheadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx

@ مارك براكيت:"تُستخدم القيود لتقييد المجال...المشغلات هي وسيلة لفرض منطق الأعمال":الأمر ليس بهذه البساطة في SQL Server لأن وظائف قيوده محدودة على سبيل المثال.لم يكتمل بعد SQL-92.خذ المثال الكلاسيكي لـ "المفتاح الأساسي" المتسلسل في جدول قاعدة البيانات المؤقتة:من الناحية المثالية، سأستخدم قيد التحقق مع استعلام فرعي لمنع تداخل الفترات لنفس الكيان ولكن SQL Server لا يمكنه القيام بذلك لذا لا بد لي من استخدام مشغل.مفقود أيضًا من SQL Server هو قدرة SQL-92 على تأجيل التحقق من القيود ولكن بدلاً من ذلك يتم التحقق منها (في الواقع) بعد كل عبارة SQL، لذا مرة أخرى قد يكون المشغل ضروريًا للتغلب على قيود SQL Server.

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

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

@ميف:هناك مشاكل محتملة في أسلوب استخدام الدالة لأنه، ببساطة، تم تصميم قيود SQL Server CHECK باستخدام صف واحد كوحدة عمل، ولها عيوب عند العمل على مجموعة النتائج.لمزيد من التفاصيل حول هذا راجع:[http://blogs.conchango.com/davidportas/archive/2007/02/19/Trouble-with-CHECK-Constraints.aspx][1].

[1]:مدونة ديفيد بورتاس:مشكلة مع قيود التحقق.

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

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

كثير من الناس لديهم طرق عديدة للقيام بذلك.ولكن هناك شيء واحد مؤكد، وهو أنه سيتعين عليك إجراء إدراج لكل تحديث/إدراج/حذف في هذا الجدول

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

وأنا أتفق مع الجميع هنا بشأن القيود.استخدمها قدر الإمكان.

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow