it-swarm.asia

واحد الخامس / ثانية قواعد بيانات متعددة

لقد قمت بإنشاء تطبيق الويب هذا (php & mysql) الذي يخزن المعلومات لمختلف المنظمات (حوالي 20 عميلًا حاليًا).

يخزن السيناريو الحالي المعلومات المتعلقة بالعملاء في قواعد البيانات الفردية ، لذلك هناك 20 قاعدة بيانات للعميل وقاعدة بيانات رئيسية واحدة.

إحدى المزايا الرئيسية هنا هي أنه كلما تم عزل كل عميل db ، يتم ترقيم ترقيم القطع الأثرية للعميل (التقارير ، ومراجعة الحسابات) وما إلى ذلك ؛ إعطاء عملائنا شعور بالأمان.

يحتوي كل قاعدة بيانات على ما يقرب من 15 جدولًا ، ومعظم الصفوف في الجدول حوالي عام 2000. ومن المتوقع أن يتم صدها حتى 5000 سجل ، على الأكثر.

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

نحن على ترتيب استضافة مشترك ، ويزودنا مزود خدمة الإنترنت الخاص بنا برقم محدود. قواعد البيانات ؛ وهذا ما دفعني إلى التفكير فيما يتعلق بمركزية قاعدة البيانات ؛ بحيث يمكن تخزين جميع بيانات العميل في قاعدة البيانات الرئيسية.

بالطبع ، بعض القضايا المهمة التي تنشأ هي:

أ. الحفاظ على تسلسل القطع الأثرية ، (يمكن معالجة ذلك عن طريق إنشاء مفتاح مرجعي إضافي) ب. السرعة والأداء (في هذه الحالة يمكنني إنشاء فهارس لتسريع الأمور) ج. الأمان: سيتم إدارتها لأن كل استعلام يجلب معلومات العميل. سوف تتبع أيضا client_id بهم

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

هل تعتقد أن الانتقال إلى قاعدة بيانات مركزية أكثر منطقية من البقاء كما نحن (في قواعد البيانات الفردية)؟

شكرا لنصيحتك.

17
Narayan

هناك ورث المخاطر والمكافآت لكلا النظام. عملت لدى شركة مالية تدعم حوالي 40 عميلًا (بنوك وطنية) في قاعدة بيانات واحدة. بعد ذلك ، اشترينا شركة أخرى باعت برامج مماثلة وذهبت إلى قاعدة بيانات واحدة لكل عميل. أخيرًا ، أفلست الشركة وكان علينا تصدير جميع بيانات المستخدم. إليكم ما وجده الأشخاص الذين عملت معهم:

برو من DB واحد:

  1. تحديثات البرامج وإصلاح الأخطاء أسهل.
  2. من السهل إدارة والإبلاغ عن جميع بيانات العميل.
  3. تحديث البيانات يصبح أسهل.
  4. من السهل إنشاء وظائف معيارية يريدها عميل واحد ، قم بإيقاف تشغيلها للعملاء الآخرين ، ثم قم بإيقاف تشغيلها عندما يرغبون في ذلك في المستقبل.

سلبيات DB واحدة:

  1. سلامة البيانات - كان لدينا حالتان أو 3 حالات شاهد فيها مستخدمو بنك واحد بيانات بنك آخر. كان هذا كابوسا. خاصة وأن مستخدمي الموقع لم يكونوا فقط موظفي البنك بل الحسابات الفعلية التي تحمل عملاء البنك! هذا هو إلى حد بعيد أكبر مشكلة مع 1 قاعدة البيانات
  2. عند تصدير بيانات العميل - عندما كان علينا ذلك ، لم تكن هذه مشكلة كبيرة. ينتهي بك الأمر بجدول واحد يحتوي على جميع العملاء فيه ويمكنك إيقاف تشغيل هذا الجدول للحصول على بيانات العميل الخاصة بك.

مؤيد قواعد بيانات متعددة:

  1. لا يوجد أي قلق بشأن تلوث بيانات العميل أو خروقاته
  2. لقد أصبح تصدير بيانات العملاء أمرًا سهلاً.

سلبيات قواعد بيانات متعددة:

  1. تحديثات وإصلاح الأخطاء - كان هذا هو الكابوس الحقيقي. عندما يكون لديك 20 عميلًا في 20 قاعدة بيانات مختلفة ، فسرعان ما تصادف وجود حالة يريد فيها عميل واحد إصلاح الخلل ويعتقد آخر أن الخلل ميزة أو لا يريد المخاطرة بالتحديث. علاوة على ذلك ، سيكون لديك حالات يريد فيها عميل واحد تحسين اللعبة ولكن العملاء الآخرين لا يريدون ذلك. عندما يحدث هذا ، ستبدأ قواعد البيانات في التباعد. فجأة ، سوف تضطر إلى تحديث العملاء من 1 إلى 15 بنص برمجي واحد من 16 إلى 19 بأخرى و 20 بالثالث. لقد رأينا أن هذه المشكلة أصبحت تتطلب إصلاح الأخطاء من 15 إلى 20 مرة للشركة التي اشتريناها من الولايات المتحدة لأنهم اضطروا إلى إجراء جميع الاختبارات لكل عميل والتعامل مع كل عميل على حدة. في الواقع ، احتاجوا إلى شخص دعم جديد لكل عميل جديد ، بينما احتاجت الشركة الأم إلى عميل لكل 5 إلى 10 عملاء.
  2. إدارة قواعد البيانات - عندما تصل إلى عدد كبير من العملاء ، فإن إدارة جميع قواعد البيانات تصبح مشكلة حقيقية. سوف تحتاج بلا شك المزيد من الوقت ديسيبل لإدارتها.

في النهاية توصيتي بعد أن رأيت وفعلت على حد سواء هو أن يكون "الانضباط"! أعتقد أن خيار الديسيبل أفضل قليلاً لأنه يحميك ، لكن لا يمكنك أبدًا السماح للعملاء بعمل خيار يجعلك تضيف وظائف لهم فقط أو ستضع نفسك على طريق الفشل.

13
Ben Hoffman

سيكون لدي قاعدة بيانات منفصلة للعملاء منفصلة. قد يطلب العميل ذلك لأسباب أمنية - أي أن موقعه هو الوحيد الذي يمكنه الوصول إلى بياناته. وهذا يعني أيضًا أنه إذا أراد العميل نقل بياناته ، فسيصبح أسهل في إدارته.

وهذا يعني أيضًا أنه إذا كانت هناك مشكلة في قاعدة بيانات عميل واحد ، فلن يؤثر ذلك على الآخرين.

إذا كنت ترغب في مقارنة البيانات بين العملاء ، فعليك القيام بذلك بشكل منفصل.

إذا كنت تنفد من قواعد البيانات التي يمكنك امتلاكها ، فربما يجب عليك التفكير في تغيير مزود الخدمة المضيف.

13
ChrisF

لإضافة إلى الموالية/يخدع المدرجة حتى الآن:

المؤيد لقواعد البيانات المتعددة:

  1. يتم تجنب القضايا قفل. لدينا قواعد بيانات حيث يمكن للعملاء تشغيل تغييرات DDL على بعض الجداول. بالنسبة للجداول الكبيرة (> 2 مليون سجل) ، يقوم هذا بإغلاق الجدول لفترة طويلة من الوقت. الأشخاص الوحيدون الذين هم في وضع غير مؤات هم مستخدموهم ، لذلك هذا مقبول.

  2. المرونة - بعض العملاء لديهم رغبات محددة فيما يتعلق بالبيانات التي يرغبون في تخزينها ؛ أتاحت لنا قاعدة البيانات المتعددة المرونة في تغيير قاعدة البيانات الخاصة بهم على وجه التحديد ، دون الاضطرار إلى تشوش نموذج البيانات للعملاء الآخرين.

سلبيات:

  1. يخدع الرئيسية: الانضمام إلى الجداول الأخرى هو الكثير مرهقة. لدينا قاعدة بيانات رئيسية تحتوي على معظم البيانات الوصفية. لا يملك مستخدمو قاعدة البيانات الخاصة بالعميل حق الوصول إلى قاعدة البيانات هذه ، لذا فإن جميع عمليات الربط بين الجداول في قاعدة البيانات تلك والقائمة الخاصة بالعميل تتم معالجتها في التطبيق بدلاً من قاعدة البيانات. يمكنك حل هذا عن طريق منح المستخدمين المعنيين بالعميل حق الوصول إلى قاعدة البيانات الرئيسية ، ولكن بعد ذلك يمكن للتطبيق/قد يسرب المعلومات من جديد.

حظا سعيدا في اختيار!

0
kander

أعلم أنك اخترت بالفعل إجابة ، لكن يبدو أن هناك حلًا آخر لم يتم اقتراحه:

انقل كل شيء إلى قاعدة بيانات واحدة ، ولكن أنشئ جداول لكل عميل ، باستخدام بادئة ، مثل هذا:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

إنه نوع من أفضل ما في العالمين.

  • من السهل جدًا الانتقال من الإعداد الحالي إلى الإعداد الجديد.
  • يمكنك إنشاء مستخدم واحد لكل عميل وتقييد امتيازاته على جداول شركته ولا شيء آخر
  • يمكنك إنشاء مستخدم خارق وتجميع البيانات بسهولة إذا كنت بحاجة إلى القيام بذلك.
  • استخدم قاعدة بيانات واحدة فقط
0
Sylver

السبب الوحيد لعدم وجود قاعدة بيانات فردية لكل عميل هو إذا كان لديك 100 أو 1000 من العملاء/قواعد البيانات. قد يكون هذا مشعرًا حقًا لإدارة بما في ذلك إجراء تغييرات قاعدة البيانات أو القيام بشيء عبر جميع قواعد البيانات. قد تكون الإجراءات التي تحدث عبر أعداد كبيرة من قواعد البيانات المتعددة بطيئة أيضًا حيث تحتاج إلى فتح (وبالتالي إغلاق) العديد من الجداول.

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

ميزة واحدة ، والتي قد لا تكون مهمة ولكن يمكن أن تكون مفيدة ، هي أن كل عميل يحصل على معرفات متسلسلة خاصة بهم (بدلاً من تخطي مجموعة لأن عميل آخر (عملاء) أضافوا سجلات).

أيضًا ، تتيح قواعد بيانات متعددة للجداول الفرعية (مثل نوع الهاتف) أن تكون قابلة للتخصيص بسهولة لكل عميل دون الحاجة إلى معرف سجل أصل في هذه الجداول أيضًا.

0
Darryl Hein

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

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

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

أعتقد أن الملصقات الأخرى قد قدمت بعض النقاط الممتازة لذلك لن أتجاوز تلك.

0
Gareth Farrington