كيف تفكّر في قاعدة البيانات قبل ما تكتب أول جدول
أكثر خطأ شفتُه يتكرر في مشاريع كثيرة — وبعضها كنت أنا جزءًا منه — هو البدء بإنشاء الجداول قبل فهم البيانات نفسها. نفتح محرر SQL، نكتب users، posts، relations… وبعد فترة نكتشف أن النظام يقاومنا بدل ما يساعدنا.
المشكلة غالبًا ما تكون في أول قرار اتخذناه، وليس في الاستعلام الأخير الذي نحاول تحسينه.
هذا المقال ليس دليلًا لإنشاء جداول، بل محاولة لتغيير طريقة التفكير قبل كتابة أي سطر SQL.
البيانات قبل الجداول
قبل ما تسأل:
كيف أصمم الجدول؟
اسأل:
ما الشيء الذي أحاول تمثيله؟
الفرق بين الاثنين كبير.
الجدول مجرد وسيلة، لكن البيانات هي الحقيقة.
مثال بسيط: “مستخدم”
هل هو:
- حساب تسجيل دخول؟
- شخص حقيقي؟
- جهة اتصال؟
- كيان له صلاحيات؟
كثير من الأنظمة تضع كل ذلك في جدول واحد اسمه users، ثم تبدأ الترقيعات لاحقًا. المشكلة هنا أنك دمجت مفاهيم مختلفة في كيان واحد فقط لأن الاسم بدا مناسبًا.
افهم دورة حياة البيانات
أي قطعة بيانات تمر بمراحل:
- متى تُنشأ؟
- متى تتغير؟
- متى تصبح غير مهمة؟
- هل تُحذف؟ أم تُؤرشف؟
إذا لم تفهم هذا من البداية، ستنتهي بجداول مليئة بحقول مثل:
- deleted_at
- status
- is_active
- is_archived
ليس لأنها ضرورية، بل لأن التصميم الأولي لم يكن واضحًا.
البيانات التي لا تُحذف يجب التفكير فيها بشكل مختلف عن بيانات مؤقتة. وهذا يؤثر على الفهارس، العلاقات، وحتى طريقة الاستعلام.
العلاقات ليست تفاصيل جانبية
كثير يبدأ بجدول، ثم يقول: “نربطه لاحقًا”.
لكن العلاقات هي قلب قاعدة البيانات، وليست إضافة.
اسأل نفسك:
- هل العلاقة ثابتة أم تتغير؟
- هل العلاقة تعني ملكية أم مجرد ارتباط؟
- هل حذف كيان يؤثر على الآخر؟
علاقة غير واضحة في البداية تعني منطق معقد لاحقًا في الكود، وتعني استعلامات ملتوية، وتعني أخطاء يصعب تتبعها.
لا تفكر في الواجهة وأنت تصمم القاعدة
من الأخطاء الشائعة تصميم قاعدة البيانات حسب ما يظهر في الواجهة.
الواجهة تتغير.
البيانات يجب أن تصمد.
إذا صممت الجدول بناءً على شاشة واحدة، ستعاني عند إضافة شاشة ثانية. قاعدة البيانات الجيدة تخدم أكثر من استخدام دون إعادة تصميم.
التطبيع ليس هدفًا بحد ذاته
التطبيع (Normalization) أداة، وليس قانونًا مقدسًا.
نعم، فصل البيانات يقلل التكرار.
لكن الإفراط في الفصل قد يحوّل كل استعلام إلى سلسلة joins طويلة بلا داعٍ.
السؤال الصحيح ليس:
“هل هذا مطبّع؟”
بل:
“هل هذا يعكس الواقع؟ وهل يخدم الاستخدام الفعلي؟”
التوقع أهم من الكمال
لا توجد قاعدة بيانات مثالية من أول مرة. لكن هناك فرق بين تصميم يسمح بالتطور، وتصميم ينهار عند أول تغيير.
فكر في:
- ما الذي قد يتغير؟
- ما الذي غالبًا سيبقى ثابتًا؟
- ما الذي قد يكبر حجمه؟
لا تصمم للمجهول، لكن صمّم وأنت مدرك أن التغيير قادم.
قاعدة البيانات ليست مجرد تخزين
قاعدة البيانات ليست صندوقًا تضع فيه البيانات ثم تنساها. هي جزء من منطق النظام.
قراراتك فيها:
- تؤثر على الأداء
- تؤثر على الأمان
- تؤثر على بساطة الكود
- وتؤثر على قابلية الصيانة بعد سنة أو سنتين