هل استخدم قاعدة بيانات لكل مشترك ؟ أم قاعدة بيانات واحدة للكل ؟

هل استخدم قاعدة بيانات لكل مشترك ؟ أم قاعدة بيانات واحدة للكل ؟

السلام عليكم ورحمة الله وبركاته

أنا مبرمج php&mysql

أحتاج استشارة ..

سأقوم ببرمجة برنامج سحابي إدارة مبيعات ونقاط بيع.

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

وذلك بغرض جعله متاحا لأصحاب المتاجر بـ اشتراك سنوي.

_____

السؤال ::

هل أجعل جميع البيانات تخزن في قاعدة بيانات واحدة ؟

أم اجعل لكل اشتراك قاعدة بيانات منفصلة ؟؟

_____________

اقتراحاتكم ؟

يرجى الدخول لحسابك أو تسجيل حساب لتستطيع إضافة تعليق
حساب جديد دخول

التعليقات

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

طالما أنه يمكنك إحتواء جميع المميزات المطروحة في تطبيقك في schema واحدة في قاعدة البيانات لذا سيكون من السهل متابعة كل المشتركين والمعالجة من لوحة أدمن واحدة مرتبطة بقاعدة البيانات.

::: المشكلة أن كل مشترك سيكون له عدد كبير جدا من البيانات المدخلة :::

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

بالنسبة لـ

لذا سيكون من السهل متابعة كل المشتركين والمعالجة من لوحة أدمن واحدة مرتبطة بقاعدة البيانات.

في حال وضعت لكل مشترك قاعدة بيانات منفصلة .

طبعا ستكون هناك قاعدة بيانات أيضا واحدة فقط لكل بيانات المشتركين الأساسية

مثل : الاسم والاميل ورقم الجوال وتاريخ الاشتراك وتاريخ انتهاء الاشتراك

نعم هذا فقط ما احتاجه في لوحة التحكم الخاصة بي

فبالطبع لا أحتاج إلى مشاهدة فواتيره الشخصية وما إلى ذلك.

يمكن في كلتا الحالتين ، ولكن إذا تريد أن يكون موقعك من نوع saas أو software as a service بحيث يمكن لكل تاجر أن يستأجر عليك هذه الخدمة ويكون له نطاق متفرع من نطاقك ، مثلا تفترض أن اسم نطاقك example.com فسيكون نطاق المسـتأجر name.example.com ، وهنا يجب تطبيق فكرة Multi-tenant database design ، وهذه أنواع تصاميمها

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

شكرا لك على ردك :: دخلتني عالم جديد أشعر بأني سأستفيد منه استفادة قوية جدا

أشكرك ::

قاعدة بيانات مشتركة. يتشارك المستأجرون الموارد والتخزين مع قاعدة بيانات واحدة مقسمة إلى أعمدة معرف (عمود لكل عميل).

هل هذه الطبيعية التي أستخدمها في العادة ؟

أي :: جداول وأضع مثلا في نهاية كل جدول UserID لتحديد ان هذا الحقل للمشترك صاحب هذا الآي دي.

هل هذا هو المقصود هنا ؟

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

بسبب حجم البيانات الكبير لكل مشترك أعتقد بأني سأستخدم هذا النوع.

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