الممارسات السيئة في تصميم قواعد البيانات: هل ترتكب هذه الأخطاء؟

عندما يتم تكليفك ، كمطور ، بمهمة بناءً على التعليمات البرمجية الحالية ، عليك مواجهة العديد من التحديات. يتضمن أحد هذه التحديات - في أغلب الأحيان الأكثر تطلبًا - فهم نموذج البيانات للتطبيق.

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

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

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

الممارسة السيئة رقم 1: تجاهل الغرض من البيانات

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

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

لكن ، بالطبع ، حجم البيانات ليس هو الجانب الوحيد الذي يجب مراعاته ، لأن الغرض من البيانات يؤثر أيضًا على مستوى التطبيع ، وهيكل البيانات ، وحجم السجل ، والتنفيذ العام للنظام بأكمله.

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

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

الممارسة السيئة رقم 2: التطبيع السيئ

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

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

إذا تعثرت في جداول لا تتوافق مع 3NF أو 2NF أو حتى 1NF ، ففكر في إعادة تصميم هذه الجداول. الجهد الذي تستثمره في القيام بذلك سيؤتي ثماره على المدى القصير جدًا.

الممارسة السيئة رقم 3: التكرار

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

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

تتمثل الآثار السيئة النموذجية للتكرار في الزيادة غير الضرورية في حجم قاعدة البيانات ، وكون البيانات عرضة لعدم الاتساق ، وانخفاض كفاءة قاعدة البيانات ، ولكن - والأهم من ذلك - قد يؤدي ذلك إلى تلف البيانات.

الممارسة السيئة رقم 4: النزاهة المرجعية السيئة (القيود)

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

الممارسة السيئة رقم 5: عدم الاستفادة من ميزات محرك DB

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

• طرق العرض التي توفر طريقة سريعة وفعالة للاطلاع على بياناتك ، وعادة ما تعمل على إلغاء تطبيعها لأغراض الاستعلام دون فقدان صحة البيانات.
• فهارس تساعد في تسريع الاستعلامات على الجداول.
• تجميع الدالات التي تساعد في تحليل المعلومات بدون برمجة.
• المعاملات أو الكتل الخاصة بجمل تغيير البيانات التي يتم تنفيذها وتنفيذها أو إلغاؤها (التراجع) في حالة حدوث شيء غير متوقع ، وبالتالي الحفاظ على المعلومات في حالة صحيحة دائمًا.
• أقفال تحافظ على البيانات آمنة وصحيحة أثناء تنفيذ المعاملات.
• الإجراءات المخزنة التي توفر ميزات البرمجة للسماح بمهام إدارة البيانات المعقدة.
• الوظائف التي تسمح بإجراء عمليات حسابية معقدة وتحويلات للبيانات.
• القيود التي تساعد على ضمان صحة البيانات وتجنب الأخطاء.
• المشغلات التي تساعد في أتمتة الإجراءات عند حدوث أحداث على البيانات.
• مُحسِّن الأوامر (مخطط التنفيذ) الذي يعمل تحت الغطاء ، مما يضمن تنفيذ كل جملة في أفضل حالاتها والحفاظ على خطط التنفيذ للمناسبات المستقبلية. يعد هذا أحد أفضل الأسباب لاستخدام طرق العرض والإجراءات والوظائف المخزنة ، حيث يتم الاحتفاظ بخطط التنفيذ بشكل دائم في DBE.

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

الممارسة السيئة رقم 6: المفاتيح الأولية المركبة

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

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

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

الممارسة السيئة رقم 7: الفهرسة السيئة

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

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

تعتمد كفاءة الفهرس أحيانًا على نوع العمود ؛ تُظهر الفهارس الموجودة في أعمدة INT أفضل أداء ممكن ، لكن الفهارس الموجودة على VARCHAR أو DATE أو DECIMAL (إذا كان ذلك منطقيًا) ليست فعالة. يمكن أن يؤدي هذا الاعتبار إلى إعادة تصميم الجداول التي يجب الوصول إليها بأفضل كفاءة ممكنة.

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

الممارسة السيئة رقم 8: اصطلاحات التسمية السيئة

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

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

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

• لا قيود على الجدول أو حجم اسم العمود. من الأفضل أن يكون لديك اسم وصفي من اختصار لا يتذكره أحد أو يفهمه.
• الأسماء المتساوية لها نفس المعنى. تجنب وجود حقول لها نفس الاسم ولكن بأنواع أو معاني مختلفة ؛ سيكون هذا مربكًا عاجلاً أم آجلاً.
• ما لم يكن ضرورياً ، لا تكن زائداً عن الحاجة. على سبيل المثال ، في الجدول "العنصر" ، ليست هناك حاجة إلى وجود أعمدة مثل "ItemName" أو "PriceOfItem" أو أسماء مشابهة ؛ "الاسم" و "السعر" كافيان.
• احذر من الكلمات المحجوزة لـ DBE. إذا كان من المقرر أن يُطلق على العمود "الفهرس" ، وهي كلمة محجوزة في SQL ، فحاول استخدام عمود مختلف مثل "رقم الفهرس".
• في حالة التمسك بقاعدة المفتاح الأساسي البسيطة (يتم إنشاء عدد صحيح واحد تلقائيًا) ، قم بتسميته "Id" في كل جدول.
• في حالة الانضمام إلى جدول آخر ، حدد المفتاح الخارجي الضروري باعتباره عددًا صحيحًا ، يسمى "Id" متبوعًا باسم الجدول المرتبط (على سبيل المثال ، IdItem).
• إذا كانت قيود التسمية ، استخدم بادئة تصف القيد (على سبيل المثال ، "PK" أو "FK") ، متبوعًا باسم الجدول أو الجداول المعنية. بالطبع ، يساعد استخدام الشرطة السفلية ("_") بشكل مقتصد في جعل الأشياء أكثر قابلية للقراءة.
• لتسمية الفهارس ، استخدم البادئة "IDX" متبوعة باسم الجدول والعمود أو الأعمدة في الفهرس. أيضًا ، استخدم "UNIQUE" كبادئة أو لاحقة إذا كان الفهرس فريدًا ، والشرطة السفلية عند الضرورة.

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

بعض الملاحظات النهائية

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

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

ولا تنسَ أنك تتعلم فقط من خلال التجريب والأخطاء والنجاحات ، لذا انطلق وابدأ الآن.