أي الطريقتين أفضل عند تصميم قواعد البيانات؟ التخصيص أم التعميم؟

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

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

الثاني, هو أن التصميم مرن و لكن المتطلب يحتاج إلى مراجعة التصميم فعلاً. في هذه الحالة إذا كان التصميم جيداً من الأساس فلا مشكلة لأن قواعد البيانات العلائقية تستوعب هذا الأمر و هو من صميم أهدافها: تغيير هيكلية البيانات دون التأثير على البيانات نفسها. بمعنى, لو أردت إضافة حقل جديد لجدول المستخدمين فلن يؤثر هذا على صلاحياتهم!

الأخير, أن تكون البيانات التي لديك لا تتبع هيكلية ثابتة تقريباً و هذا ممكن فعلاً و لكني أشك أن هذه الحالة تنطبق على البيانات التي ذكرتها. في هذه الحالة قواعد البيانات العلائقية ليست الحل الأنسب و هناك حلول أفضل.

تحياتي...

Khaled.Alshaya كتب:

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

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

شكراً لك؛ هذا يتعلق بخطأ جوهري في التصميم لا أتحدث عنه وحله كما ذكرت التخطيط الجيد والفهم لمبادئ قواعد البيانات..

Khaled.Alshaya كتب:

الثاني, هو أن التصميم مرن و لكن المتطلب يحتاج إلى مراجعة التصميم فعلاً. في هذه الحالة إذا كان التصميم جيداً من الأساس فلا مشكلة لأن قواعد البيانات العلائقية تستوعب هذا الأمر و هو من صميم أهدافها: تغيير هيكلية البيانات دون التأثير على البيانات نفسها. بمعنى, لو أردت إضافة حقل جديد لجدول المستخدمين فلن يؤثر هذا على صلاحياتهم!

صحيح، ولكن لو كنت سأعدل على البنية لاحقاً فلماذا لا أبدأ إذن ببنية مرنة إلى حد كبير وهو ما قصدته بالتعميم من البداية؛ فما الفرق بين الأمرين؟

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

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

هذا مثال مصغر لما يمكن أن يحصل مع قواعد البيانات في المشاريع الضخمة والصعوبة الأكبر في المشاريع ذات قواعد البيانات المتعددة أو الغير مركزية بمعنى أن العميل ليس واحداً وليس التعديل في مكان واحد وليس على قاعدة واحدة وليس من السهولة بمكان..

Khaled.Alshaya كتب:

الأخير, أن تكون البيانات التي لديك لا تتبع هيكلية ثابتة تقريباً و هذا ممكن فعلاً و لكني أشك أن هذه الحالة تنطبق على البيانات التي ذكرتها. في هذه الحالة قواعد البيانات العلائقية ليست الحل الأنسب و هناك حلول أفضل.

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

بارك الله فيكم وجزاكم الله خيراً

اقتباس

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

هذا مثال مصغر لما يمكن أن يحصل مع قواعد البيانات في المشاريع الضخمة والصعوبة الأكبر في المشاريع ذات قواعد البيانات المتعددة أو الغير مركزية بمعنى أن العميل ليس واحداً وليس التعديل في مكان واحد وليس على قاعدة واحدة وليس من السهولة بمكان..

الحل في هذه الحالة ليس بناء كل شيء من الصفر و لكن عمل تخصيص لـ ERP إن كان عميلك بهذا الحجم, أو العملاء حسب قولك. إضافة إلى ذلك, لا يمكن لمبرمج واحد القيام بما تريده, أعمل كـ SAP Developer و هناك جيش من محللي النظم بيننا و بين العملاء :)

Khaled.Alshaya كتب:

الحل في هذه الحالة ليس بناء كل شيء من الصفر و لكن عمل تخصيص لـ ERP إن كان عميلك بهذا الحجم, أو العملاء حسب قولك. إضافة إلى ذلك, لا يمكن لمبرمج واحد القيام بما تريده, أعمل كـ SAP Developer و هناك جيش من محللي النظم بيننا و بين العملاء :)

ليس جنوناً.. ولكن فعلاً قد أحتاج لبناء SAP جديد ولكن في تخصص آخر.. هنا ستكون الكارثة، ونعود للسؤال الأول.

في الغالب الإضافات التي يطلبها العميل حقول معلومات ليس لها علاقة ببنية التصميم ومنطق العمل

يعني مثلا في المخازن او الموارد البشرية تستطيع عمل تصميم يلبي احتياجات اي مؤسسة في العالم

لان التصميم ومنطق العمل واحد ، جميع المخازن لديها جدول items وجدول category وجدول inventory

في الغالب اضافات العميل عبارة عن حقول بيانات ليس لها علاقة او لا تؤثر على صلب التصميم

او مثلا تقارير ممكن تعملها بشكل طبيعي

أنظمة الاي ار بي ماشية بالطريقة هذي

لو لك اهتمام اكثر في الموضوع ادرس الـ erp تبع اوراكل Oracle E-Businss Suite 12

وراح تلاحظ انهم واضعين أشياء مثل Flex Field وغيرها

بحيث واضعين مساحة للعميل ممكن يتحكم فيها ، لكن موجود لها حدود بحيث ما تؤثر على صلب العمل

إذا العميل طلب شيء ممكن يؤثر على التصميم نفسه، في الغالب ان الفكرة غير منطقية وعليه ان يتماشى مع أفضل الممارسات (best practices) الي ماشين عليها أغلب المؤسسات

أو قد يطلب العميل شيء فعلا منطقي لكن نظام اوراكل يظل قاصر ويصير عيب في النظام نفسه ممكن يجي مبرمج خبير ويضيف هذي الاضافة ويرقع نظام اوراكل المرقع من الأساس أصلا

وفيه نظام اي ار بي قادم بقوة ومجاني كمان!! opensource ويهدد الكيانات العظمى مثل اوراكل وغيرها وحسب ما قريت ان اوراكل تطمع بشرائه خوفا منه

اسمه openERP لكن الله اعلم، لم اجرب استخدام هذا النظام،

بس من تعاملي مع اوراكل erp هو جيد بشكل عام لكنه قبيح وبشع نوعا ما واحيانا كثيرة تحتاج عمل workarounds عشان تعمل الي تبيه

غير حجمه الفظيع 80 جيجا ولو تبي تعمله تسطيب مسألة طويلة لازم خبير تسطيب، للي حابب يجرب النظام من غير تسطيب فيه نسخ في الويب للتعلم والتجربة

سبق ودرست بعص الموديولس من اوراكل اي ار بي واستفدت كثيرا من ناحية اني فهمت كيف البرامج تعمل وكيف البزنس ماشي

يعني مثلا لو تدرس اوراكل المخازن والمشتريات، أكثر التركيز كيف تفهم عمل المخازن والمشتريات،

بعدها لو انت مبرمج جيد تقدر تسوي نظام مخازن جديد ويكون قوي وبسيط في نفس الوقت،

نفس الشيء في موديولس الفاينانشال لو حابب تدرسها لازم تذاكر أيضا محاسبة، بس بعدها ممكن انت كمبرمج انك تبرمج نظام محاسبي محترم لعميل معين

رائع جزاكم الله خيراً..

أضيف أيضاً أنه في حالة التعميم حسب ما وصفتها سنخسر إلى حد كبير ال normalization ونتحول غالباً إلى Denormalization database ولكل ميزات ومساوئ..

بحسب قرائتي السريعة للموضوع فهمت التالي :

نريد بناء تطبيق لا تعتمد جداول البيانات على بعضها البعض بمعنى في حال تعديل جدول سيؤدي بالضرر ببنية التطبيق

ساطرح طرح من الممكن ان يفيد :

لم لا نستخدم native XML database وتخزين البيانات كملفات xml بدون ترابط بينها وهذا سيوءدي الى بنية مرنة

مع العلم انه بالامكان تطبيق العلاقات بين الملفات ( واحد لواحد - عديد لعديد - واحد لعديد )

صراحة انا ارى التعميم مشكلة مطور من الممكن انك تعاني منها بحسب ما رايت انك تريد اطار عمل وعلى اساسه انت تقوم باضافة خصائص وكيانات اضافية وها ليس جيدة في مجمل الاحيان

لانك ستكتب اكواد اضافية لا داعي لها في تطبيقات عديدة

انا مع التخصيص ولكن مع التصميم الجيد