شرح قواعد البيانات لبوتات Discord

متى يحتاج البوت Database فعلاً؟

البيانات الدائمة مثل إعدادات Guild وسجلات الإدارة وتفضيلات المستخدمين وEconomy Balances تحتاج تخزين يبقى بعد إعادة تشغيل التطبيق.

أما المعلومات المؤقتة اللي تقدر تعيد إنشائها بسهولة، مثل بعض Cooldowns القصيرة، فمو دائماً تحتاج Database.

• إعدادات كل Guild مثل Channel IDs أو Feature Toggles.
• User Profiles والتفضيلات.
• Moderation Cases والتحذيرات.
• Economy Balances والإحصائيات الدائمة.
• Scheduled Tasks اللي لازم تبقى بعد Restart.

صمم البيانات قبل اختيار نوع Database

حدد الـEntities والعلاقات بينها. إذا كل Guild عنده Configuration واحد، وضح هذا التصميم قبل اختيار النظام.

Relational Database مناسبة للبيانات ذات العلاقات الواضحة، بينما Document Database قد تكون مناسبة لبيانات بطبيعة Document. ماكو نوع واحد هو الأفضل لكل بوت.

• حدد Unique Key مثل guild_id أو user_id.
• حدد الحقول المطلوبة والاختيارية.
• حدد الحقول اللي راح تبحث أو ترتب عليها باستمرار.
• لا تكرر نفس المعلومة بعدة أماكن بدون سبب واضح.

مثال SQL بسيط

ممكن تبدأ بجدول واضح لإعدادات Guild. المشاريع الكبيرة تحتاج Migrations وقيود أكثر، لكن Structure واضح من البداية يسهل التطوير لاحقاً.

CREATE TABLE guild_settings (
  guild_id VARCHAR(32) PRIMARY KEY,
  prefix VARCHAR(16) NOT NULL DEFAULT '!',
  log_channel_id VARCHAR(32) NULL
);

خلي Credentials خارج Source Code

Database Password وConnection String تعتبر Secrets. لا تحطها داخل Public Repository ولا تعرضها في Screenshot.

مررها من Environment وقت التشغيل. إذا Secret تسرب، غيره من المصدر ولا تعتمد فقط على حذف الرسالة القديمة.

• استخدم Database Account بصلاحيات التطبيق فقط.
• لا ترسل Connection String كامل بالدعم أو GitHub.
• غيّر Credentials بعد أي تسريب.

DATABASE_URL=postgresql://USER:PASSWORD@HOST:5432/DATABASE

إدارة Connections بشكل صحيح

فتح Connection جديد لكل Event ممكن يسبب Overhead ويستهلك Connection Limit. أغلب Libraries توفر Client أو Connection Pool يعاد استخدامه.

خلي تهيئة Database بمكان واضح داخل التطبيق وتعامل مع فشل الاتصال برسالة مفهومة بدون طباعة Secrets داخل Logs.

• أعد استخدام Client أو Pool حسب Library.
• حدد Timeouts منطقية.
• لا تطبع Password أو Secret URL في Log.
• لا تسوي Retry سريع بلا Delay إلى ما لا نهاية.

Migrations وIndexes وBackups

لما يتغير البوت غالباً يتغير شكل البيانات. خلي Schema Changes قابلة للتكرار بدل تعديل Production يدوياً كل مرة.

Indexes لازم تخدم Queries حقيقية، والBackup لازم تختبر استرجاعه مو فقط تتأكد أن الملف موجود.

• وثق Schema Changes المهمة.
• استخدم Index للبحث المتكرر عند الحاجة.
• خذ Backup قبل Migration خطير.
• اختبر Restore على نسخة آمنة.

Checklist قبل تشغيل Database بالإنتاج

قبل الانتقال من التطوير المحلي للاستضافة المستمرة، اختبر المسار الكامل من Credentials إلى القراءة والكتابة والاسترجاع.

1. تأكد أن Database موجودة ويمكن الوصول لها من بيئة الاستضافة.
2. خزن Credential داخل Secret أو Environment Variable.
3. شغل Migrations المطلوبة.
4. اختبر Read وWrite حقيقي من البوت.
5. أعد تشغيل البوت وتأكد أن البيانات بقيت.
6. تأكد أن عندك طريقة واضحة للBackup وتغيير Credentials.

الأسئلة الشائعة

شروحات مرتبطة