10 جداول يحتاجها كل SaaS:مخطط قاعدة البيانات
10 جداول يحتاجها كل SaaS: المؤسسات والمستخدمون وسجل النشاط وغيرها، مع الأمر الجاهز للنسخ الذي يجعل الذكاء الاصطناعي يبنيها كلها بشكل صحيح.
10 جداول يحتاجها كل SaaS تشغّل 90% من تطبيقات الأعمال: المؤسسات، المستخدمون، أعضاء المؤسسة، كيانك الرئيسي، التصنيفات، العلاقات، سجل النشاط، الملفات، الإشعارات، والإعدادات. لا تعيد اختراع قاعدة البيانات — تنسخ هذا الهيكل، وتغيّر بعض الأسماء، وتطلق منتجك. هذا هو المخطط الكامل، وكيف ترتبط الجداول، والأمر الجاهز للنسخ واللصق الذي يجعل الذكاء الاصطناعي يبنيها كلها بشكل سليم.
الجدول ليس أكثر من جدول بيانات منظّم: كل صف يمثل شيئاً واحداً (مهمة، جهة اتصال، فاتورة)، وكل عمود يمثل معلومة عن ذلك الشيء. إذا كان هذا جديداً عليك، فابدأ بـشرح قواعد البيانات لروّاد الأعمال غير التقنيين ثم عد إلى هنا. فكرة هذا المقال أبسط: لست بحاجة إلى فهم قواعد البيانات لتصميم واحدة. تحتاج فقط إلى معرفة أي الجداول تنشئ — وهي تقريباً نفسها في كل SaaS.
10 جداول يحتاجها كل SaaS
التصميم السيئ لقاعدة البيانات يكسر تطبيقك عندما يكبر. والتصميم الجيد يجعل تطبيقك يعمل ببساطة. هذا هو الأساس:
| # | الجدول | ما الذي يخزّنه | لماذا تحتاجه |
|---|---|---|---|
| 1 | المؤسسات | كل شركة تستخدم تطبيقك — الاسم، الإعدادات، مستوى الاشتراك، الحالة | تعدد المستأجرين: كل عميل هو مؤسسة |
| 2 | المستخدمون | كل شخص يمكنه تسجيل الدخول — البريد الإلكتروني، الاسم، الصورة (كلمات المرور يتولاها Supabase) | المصادقة: من يستطيع الوصول إلى التطبيق |
| 3 | أعضاء المؤسسة | أي المستخدمين ينتمون إلى أي المؤسسات، ودور كل منهم (مالك، مدير، عضو، مشاهد) | يمكن للمستخدم الواحد أن ينتمي إلى عدة مؤسسات |
| 4 | كيانك الرئيسي | الشيء الذي يديره تطبيقك: مهام، جهات اتصال، فواتير، مواعيد، منتجات | هذا هو منتجك — وكل ما عداه يدعمه |
| 5 | التصنيفات / الوسوم | طرق لتجميع كياناتك الرئيسية، بأسماء وألوان | يحتاج المستخدمون إلى تنظيم الأشياء وتصفيتها |
| 6 | العلاقات | روابط متعدد-إلى-متعدد: مهام مسندة لعدة مستخدمين، ومستخدمون في عدة فرق | معظم العلاقات في الواقع ليست واحداً-لواحد |
| 7 | سجل النشاط | من فعل ماذا، ومتى، وعلى أي سجل | مسار تدقيق، وخلاصات النشاط، وتتبع الأخطاء، والامتثال |
| 8 | الملفات | مراجع للملفات المرفوعة — الاسم، الرابط، الحجم، من رفعها، وبماذا ترتبط | تقريباً كل تطبيق يتيح للمستخدمين رفع شيء ما |
| 9 | الإشعارات | تنبيهات المستخدمين — الرسالة، النوع، حالة القراءة، الرابط | يحتاج المستخدمون إلى معرفة ما يحدث |
| 10 | الإعدادات | إعدادات المؤسسة (المنطقة الزمنية، العملة) وتفضيلات المستخدم (المظهر، اللغة) | كل مستخدم يريد تخصيص تجربته |
لاحظ كم هو قليل ما يخص فكرتك تحديداً. 90% من قاعدة بياناتك مثل أي تطبيق أعمال آخر، و10% فقط منطق عملك الفريد. ابدأ بالـ90%، وابنِ الـ10%، وأطلق منتجك.
الكتابThe Solopreneur Revolutionلويس غونسالفيس عن بناء مشروع رائد أعمال منفرد بالذكاء الاصطناعي دون ترك وظيفتك.احصل على الكتاب ←كيف ترتبط الجداول ببعضها
تخيّل مبنى سكنياً. المؤسسات هي سجل المبنى — قائمة المستأجرين. المستخدمون هم السكان. وأعضاء المؤسسة هو دليل الشقق الذي يقول إن جون يسكن في الشقة 5 وسارة في الشقة 12. ومن هناك تصبح السلسلة منطقية: المؤسسة لديها كثير من كيانك الرئيسي (مهام، جهات اتصال، فواتير)، ويمكن إرفاق ملفات بكل واحد منها، وكل إجراء يولّد سجلاً في سجل النشاط، والأحداث المهمة تنشئ إشعارات.
مثال ملموس — نظام CRM بسيط يحتاج: المؤسسات (عملاؤك)، المستخدمون (من يسجلون الدخول)، أعضاء المؤسسة (جون يعمل في شركة وسارة في أخرى)، جهات الاتصال (سجلات الـCRM)، وسوم جهات الاتصال (عميل محتمل ساخن، عميل محتمل بارد، عميل)، سجل النشاط (كل تفاعل)، الملفات (مستندات مرفقة بجهات الاتصال)، الإشعارات (تنبيهات عندما تتخذ جهة اتصال إجراءً)، والإعدادات (تفضيلات كل مؤسسة). هذا كل شيء. تسعة جداول. نظام CRM كامل.
ولهذا أيضاً ينجح تصميم الجداول قبل بناء الشاشات بهذا الشكل — وهذه هي حجة التطوير بقاعدة البيانات أولاً بأكملها. الشاشات تتغير كل أسبوع. أما هذا الهيكل فبالكاد يتغير.
الجداول التي لا تحتاجها عند الإطلاق
بأهمية الجداول العشرة التي تبنيها، تلك التي تتجاوزها. أضف هذه لاحقاً عندما تحتاجها فعلاً:
- الفوترة والاشتراكات — أضفها عندما تصبح جاهزاً للتحصيل
- الفرق — أضفها عندما تكبر المؤسسات
- التكاملات — أضفها عند الربط بأدوات أخرى
- التقارير — أضفها عندما يحتاج المستخدمون إلى التحليلات
- الـWebhooks — أضفها عند بناء واجهة API
- سجلات التدقيق — أضفها لمتطلبات الامتثال والأمان
القاعدة: ابدأ صغيراً وأضف الجداول عند الحاجة. قاعدة البيانات طبقة واحدة من صورة أكبر — يرسم لك الأنظمة الـ18 التي يحتاجها كل SaaS بقية الصورة — لكن الجداول هي نقطة البداية، لأن كل شيء آخر يقوم عليها.
الأمر الجاهز للنسخ الذي يبني الجداول العشرة
أنت لا تكتب هذا الـSQL بنفسك. تسلّم الذكاء الاصطناعي المخطط ومتطلبات الجودة في أمر واحد:
Create these database tables for a multi-tenant [your app type]:
FOUNDATION: 1. organizations (id, name, slug, settings, tier, is_active, created_at, updated_at) · 2. users (handled by Supabase Auth) · 3. organization_members (organization_id, user_id, role)
CORE FEATURE: 4. [your main entity] with organization_id, your specific fields, audit columns
SUPPORTING: 5. categories (for organising [your main entity]) · 6. files (attachments) · 7. activity_log (tracking all actions) · 8. notifications (user alerts) · 9. settings (preferences)
Requirements: every table needs organization_id (except users) · add indexes on all foreign keys · enable Row-Level Security · use soft deletes (deleted_at column) · add audit columns (created_at, created_by, updated_at, updated_by)
Show me the complete SQL migration.
سيولّد الذكاء الاصطناعي الجداول مترابطة بشكل صحيح، ومتعددة المستأجرين، وجاهزة للإنتاج. كتلة المتطلبات ليست زينة اختيارية — فوجود organization_id في كل جدول وتفعيل أمان مستوى الصفوف (Row-Level Security) هما ما يمنع العميل أ من رؤية بيانات العميل ب.
الحد الأدنى للإطلاق
قبل أن تبدأ ببناء الميزات، تحقق من وجود: جدول المؤسسات، والمستخدمين (يوفره Supabase)، وأعضاء المؤسسة، وكيانك الرئيسي، وطريقة واحدة على الأقل لتنظيم العناصر، وسجل النشاط، والإشعارات. بهذه الجداول السبعة كحد أدنى، يمكنك البناء والإطلاق. أضف الباقي مع نموّك.
معظم المؤسسين يقضون أسابيع في القلق على تصميم قاعدة البيانات كأن تطبيقهم فريد من نوعه. وهو ليس كذلك — وهذه هي الأخبار الجيدة. الأساس مشكلة محلولة. انسخه، وخصّص الـ10%، ووجّه طاقتك إلى الجزء الذي لا يستطيع بناءه سواك.
12 أسبوعاًمسيرتك في الشركات لم تكن الخطة أبداًقدّم طلبك إلى Solopreneur Accelerator.قدّم الآن ←الأسئلة الشائعة
هل أحتاج فعلاً إلى كل الجداول العشرة قبل الإطلاق؟
لا — 7 منها هي الحد الأدنى: المؤسسات، المستخدمون، أعضاء المؤسسة، كيانك الرئيسي، طريقة واحدة لتنظيم العناصر (تصنيفات أو وسوم)، سجل النشاط، والإشعارات. الملفات والعلاقات والإعدادات يمكن أن تأتي مع الميزات التي تحتاجها. أما الفوترة والفرق والتكاملات والتقارير والـWebhooks فتأتي بعد ذلك بكثير.
ماذا يعني "تعدد المستأجرين" ولماذا هو مهم؟
تعدد المستأجرين يعني أن عدة عملاء يتشاركون تطبيقاً واحداً بينما يرى كل منهم بياناته فقط. ولهذا يأتي جدول المؤسسات أولاً ولهذا يحمل كل جدول organization_id. ومع أمان مستوى الصفوف، يُضمن أن تبقى سجلات كل عميل داخل جدرانه الخاصة — مثل الشقق في مبنى واحد.
هل يستطيع الذكاء الاصطناعي فعلاً تصميم قاعدة بياناتي؟
نعم — إذا أعطيته المخطط. الصق الأمر أعلاه بعد ملء كيانك الرئيسي وسينتج الذكاء الاصطناعي ملف الترحيل SQL كاملاً: الجداول والمفاتيح الأجنبية والفهارس وأمان مستوى الصفوف. ما لا يستطيع الذكاء الاصطناعي فعله هو تحديد ما هو كيانك الرئيسي. هذا قرار منتج، وليس قراراً تقنياً.
ما "الكيان الرئيسي" لتطبيقي؟
الشيء الواحد الذي يديره تطبيقك. مدير المهام ← المهام. نظام CRM ← جهات الاتصال. الفوترة ← الفواتير. الحجوزات ← المواعيد. التجارة الإلكترونية ← المنتجات. إذا لم تستطع تسميته بكلمة واحدة، فلم تحدد منتجك بدقة كافية بعد — عالج ذلك قبل أن تلمس قاعدة البيانات.
إلى أي حد أنت محاصر فعلاً؟
أجرِ مؤشر الاختناق الوظيفي، التقييم المجاني لمعرفة مدى استعدادك لتصبح رائد أعمال منفرداً.