قاعدة البيانات هي قلب أي تطبيق ويب. واختيار قاعدة البيانات الصح قرار بياثر على كل حاجة في المشروع: الأداء، الأمان، قابلية التوسع، وحتى سرعة التطوير. في المقال ده هشارك رحلتي مع قواعد البيانات من SQLite لـ PostgreSQL، وإزاي Prisma غيّر طريقة تعاملي مع البيانات.
بدأت بـ SQLite في أول مشاريعي. SQLite ممتاز للمشاريع الصغيرة والنماذج الأولية — مفيش سيرفر لازم تشغله، الملف بتاع قاعدة البيانات بيتحط في المشروع نفسه، وكل حاجة شغالة فورًا. في مشروع بسيط زي نظام الإقبال في البداية، SQLite كان كافي. بس لما المشروع كبر ولما عدد المستخدمين زاد، ظهرت مشاكل: SQLite مش بيقدر يتعامل مع اتصالات متزامنة كتير، ومفيش Features متقدمة زي Full-Text Search أو JSONB.
الانتقال لـ PostgreSQL كان نقطة تحول. في إسمع راديو، كان محتاجين قاعدة بيانات تتعامل مع آلاف المحطات ومئات المستخدمين في نفس الوقت. PostgreSQL وفّر ده وأكتر. دعم JSONB خلاه سهل أخزن بيانات المحطات المتغيرة بدون ما أعمل Schema معقد. كمان Full-Text Search الأصلي ساعدني أعمل بحث سريع في أسماء المحطات بدون مكتبات خارجية.
Prisma ORM كان الحلقة اللي ربطت كل حاجة. بدل ما أكتب SQL يدوي واتعامل مع الاتصالات والـ Migrations، Prisma وفّرلي Schema واضح ومقروء، TypeScript types تلقائية، وMigration system بيدير التغييرات في قاعدة البيانات. في طمني، الـ Schema كان بسيط وواضح: موديل User، موديل LocationShare، موديل FamilyCircle. كل علاقة معرّفة بوضوح في ملف schema.prisma.
من أكبر فوائد Prisma: الـ Type Safety. لما بتكتب كود بتاعك، كل حاجة ليها نوع واضح. لو حبيت تعمل Query على المستخدمين، Prisma بيرجعلك Type دقيق فيه كل الحقول اللي في الموديل. ده بيمنع أخطاء كتير جدًا وبيخلي الـ autocomplete يشتغل بشكل ممتاز. في معركة الأسئلة، الـ Types ساعدتني أتعامل مع بيانات اللاعبين والجولات بدون أي خطأ في وقت التشغيل.
بس Prisma مش كامل. من أكتر الحاجات اللي بتزعلني: الـ N+1 Query Problem. لما بتعمل query على موديل ليه علاقات، أحيانًا Prisma بيعمل query لكل سجل على حدة بدل ما يعمل JOIN واحد. الحل هو تستخدم include بذكاء أو تفعّل_previewFeatures = "relationJoinMode" عشان تجبر Prisma يستخدم JOINs. كمان Prisma مش بيقدر يعمل بعض الـ Queries المعقدة اللي SQL بيعملها بسهولة، زي Window Functions أو CTEs. في الحالات دي، بتضطر تستخدم $queryRaw وتكتب SQL يدوي.
تصميم الـ Schema فن بحد ذاته. من أهم الأنماط اللي تعلمتها: استخدم علاقات كتيرة لكثير (Many-to-Many) عبر جداول وسيطة بدل ما تحاول تختصرها. في إسمع راديو، العلاقة بين المحطات والمستخدمين (المفضلات) كانت Many-to-Many، وعملت جدول وسيط Favorite فيه تواريخ وبيانات إضافية. كمان تعلمت إن الـ Indexes مش رفاهية — كل حقل بتدور عليه كتير لازم يكون عليه Index. بعد ما أضفت Index على اسم المحطة، البحث بقي أسرع بـ 10 مرات.
استراتيجية الـ Migration مع Prisma كانت نقطة قوة. كل تغيير في الـ Schema بيعمل Migration جديد فيه التغييرات بس، مش قاعدة البيانات كلها. ده بيخلي التراجع عن التغييرات سهل وبيحفظ تاريخ التعديلات. بس لازم تكون حذر: Migration اللي اتعمل ميرجعش بسهولة لو فيه بيانات موجودة. عشان كده دايماً بعمل Backup قبل أي Migration كبير.
نصيحتي للي بيبدأ: ابدأ بـ SQLite عشان السرعة في التطوير، بس خطط للانتقال لـ PostgreSQL من الأول. استخدم Prisma عشان الـ Type Safety والـ Migrations، بس اتعلم SQL كويس عشان تعرف تعمل Queries معقدة لو احتجت. ودايمًا اختبر أداء قاعدة البيانات مع بيانات حقيقية مش بيانات تجريبية صغيرة.