مثل ما أن للبرمجة Design patterns اي اساليب مجربة لحل المشكلات فكذلك هنا Design patterns لجداول قواعد البيانات
هي خبرات من سبقونا. ذكرت في تغريدات سابقة ان الORM قتلت المقتول و الذي هو الObject Oriented programming
لكن دعونا نتماشى مع طلب السوق.
(سلسلة)
هي خبرات من سبقونا. ذكرت في تغريدات سابقة ان الORM قتلت المقتول و الذي هو الObject Oriented programming
لكن دعونا نتماشى مع طلب السوق.
(سلسلة)
مكتبات الORM ربطت الObjects مع الTables فأصبح تفكيرنا وقت التحليل و التصميم منصب على كيف ستكون جداولنا في قاعدة البيانات و بعدها من خلال البرنامج نتلاعب بتلك الكلاسات التي هي مجرد حاضنة للبيانات و نقرر اين سنخزنها و كيف نقرأها مع بعض العلاقات.
هنا اصبحت الكلاسات مجرد أكياس setters و getters كما اسماها مارتن فاولر ولم تصبح كلاسات بالمعنى الحقيقي الذي يفترض ان يكون فيه الكلاس برنامج متكامل محكم و مغلق في نفس الوقت. و يُتعامل معه فقط من خلال methods تعمل كInterfce و لها معنى و غرض حقيقي وليس مجرد set و get لخصائص الكلاس.
لنتغاضى عن جزئية الكلاسات و ننتقل لقواعد البيانات. لو ركزنا سنجد أن الORM تسببت ايضاً بنفس الأذى لقواعد البيانات. حيث اصبحت الجداول عبارة عن seed model بسيط جداً كـ99% من من قواعد البيانات التي ترونها في الدورات و كتب تعليم البرمجة للمبتدئين,
ستجدون مثلاً جدول يمثل امر شراء يرتبط بجدول عملاء و يرتبط به عدة منتجات ثم جدول تفاصيل الطلب و ربما جدول لطريقة الدفع و هكذا. تمثيل بسيط جداً لواقع معقد جداً.
أو مثلاً لمشروع مدرسة جدول فصول به طلاب و كل طالب مرتبط بمادة ثم مدرس مرتبط بالمادة و الفصول و هكذا. لكن الواقع في البرامج الكبيرة مختلف , فهناك كما ذكرت Patterns يمكن تطبيقها عند نمذجة اي مشروع بعد تحديد هيكلة البيانات.
في عالمنا الحقيقي البيانات لاتأتي جاهزة في صورة جداول, هناك بيانات شجرية يكون فيها لكل عقدة او ورقة أب واحد و هناك بيانات Graphs قد يكون لورقة اكثر من أب و هناك علاقات نجمية و غيرها و لكل نوع كالشجرية مثلا ستجد من 5 الى 6 انواع فرعية.
ايضاً اهمية البيانات ليست سواء. و معدل تغييرها ايضاً ليس سواء حتى لو كانت مجرد وصوف لشيء واحد و من غير الجيد ان نصفها في جدول واحد. لأن الواقع ليس هكذا. الNormalization هنا لا تخدمنا فهي مجرد مباديء و ليس انماط تصميم.
معرفة ما سبق يعتمد على فهمنا للمشكلة و ليس للحل. نمذجة البيانات تأتي في جزئية التحليل و ليس التصميم , دائماً نقرأ Object Oriented Analysis and Design لكننا نرى الDesign و الPatterns الخاصه به و لا نرى شيئاً للAnalysis. لا اتكلم هنا عن الBusiness Analysis فالموضوع مختلف تماماً.
الAnalysis ايضاً لها patterns تماما كما ان هناك Design patterns و الفرق ان الAnalysis يكون للProblem space بعكس الDesign patterns التي هي للSolution Space هذه من بعض مفاهيم الDomain Driven Design.
اذا لم تطلع على الdatabase design patterns و قمت بتصميم قاعدة بيانات خدمتك لسنين فهو امر من ثلاثة : إما انك طبقت احد الpattern من دون أن تدري ولكن اخذت وقتا وجهدا لاكتشافه وهو موجود, او انك استخدمت antipattern ينصح بعدم استخدامه أو انك استحدثت pattern جديد تستحق نشره باسمك.
السؤال إين اتعلم هذا؟. اعرف كتابين فقط الأول و هو الأفضل لدي اسمه patterns of data modeling للمؤلف Michael Blaha و به امثلة كافية مع جمل الsql و الرسومات و الكتاب الآخر لDavid Hay اسمه Data Model Patterns. و اعتقد ان الأول كاف جداً و هو حوالي 250 صفحة فقط.
دمتم بود.
دمتم بود.
جاري تحميل الاقتراحات...