بآخر جزء من مقالنا الثالث ، Database Design ، بعد ما اتكلمنا بالجزء الأول عن الضوابط البتحكمنا في تصميم ال Database (ال ACID vs BASE) ، في الجزء الثاني اتكلمنا عن القوانين البنستخدما في تصميم ال Data Entities نفسها في حالة ال Relational Database و ال Non-relational Database ، صار وقت نختم مقالنا بكيف نختار نوع الداتابيز المناسب النا في بناء نظامنا ، بين ال Relational Database و ال Non-relational Database.
قبل ما نبدا ، لازم اوضح انو الفروقات بين ال relational و ال non-relational بدات تبقا بسيطة ، لانو كل نوع من النوعين بدا يعمل خواص النوع الثاني كجزء من المميزات اللي بيقدما ، مثل ال JSONB الموجود في PostgreSQL و ال Multi-document transactions في MongoDB. فالنوعين بحاولو دايما يعززو من المميزات البقدموها لجذب كمية مطورين اكبر لاستخدامهم ، هالشي خلا لاغلب التطبيقات العملية البسيطة او ذات ال scale الصغير ما يفرق معها اي نوع من النوعين هو الانسب الها.
و لكن طبعا بيفضل في عندي فروقات جوهرية و كتير واضحة لما تطبيقنا العملي بيبدا يزداد في التعقيد و يكبر في ال scale.
و بهالحالة ، لما بنتخذ قرار اي واحد من انواع الداتابيز هو الانسب النا ، ف هالشي بيتحدد عن طريق وقوعك باحد السيناريوهات التالية:
1- حالات اختيار Relational Databases:-
- اذا عندي Data Structure متوقع: في حال كانت ال Data entities عندي مستقرة من ناحية الخواص أو ال attributes اللي بتوصفا ، أو التغييرات اللي ممكن تطرأ عليها ماهي تغيرات جوهرية بشكل كبير ، فهالشي بسهل علينا التصميم اللي بكون Optimized و جاهز لل scale الكبير بسبب الثبات و التوقع لأي تغييرات على ال Data entities.
- اذا كان نظامي بيستفيد من ال ACID operations: في حال كان عندي سيستم بيلزمني باستخدام ال ACID rules ، ف الحل الانسب هو استخدام نوع الداتابيز المصمم للتعامل مع ال use cases اللي بيطرحا اطار عمل ال ACID ، و اللي هو ال Relational Databases.
- في حال كان مطلوب مني عمليات Read معقدة: كلنا بنعرف انو ال JOIN بتوفرلنا اريحية كبيرة جدا بتحديد شكل الداتا اللي ممكن نستخدما بمختلف حالات النظام (عمل Data Analysis ، استخراج Ad-Hoc Reports بشكل دوري ، كثرة أشكال ال Queries اللي بيحتاجا نظامنا من نفس ال Data Entitiles ، …) ، فبنلاقي ان ال Relational Databases بتوفرلنا اريحية و عملية كتير كبار بتحديد شكل ال Read Queries حسب اي حالة ممكن تلاقينا.
2- حالات اختيار Non-relational Databases: رح نلاقي ان كل الآتي هو عكس الحالات أعلاه:-
- اذا كان عندي Data Structure متغير بشكل مستمر: مثال على هالشي اذا كان عندي مجمع تجاري بيأجر محلات لمختلف انواع المجالات التجارية ، و كل محل تجاري رح يكون عندو شكل معين من الداتا اللي بتميزو عن باقي المحلات. بهالحالة ، خيار ال Non-relational Database بكون انسب لانو بيعطينا اريحية بتغيير شكل ال Data Entities على حسب كل use case لكل محل تجاري.
- اذا كان نظامي بيستفيد من ال BASE operations: في حال كان السيستم اللي ببنيه بيعتمد على ال BASE operations في عملو ، ف خيار ال Relational Database رح يكون معقد و صعب التطبيق بالصورة المطلوبة لتحقيق هالشي ، و الخيار الأنسب هو انو نستخدم Non-relational Database.
- في حال كان مطلوب من النظام عمليات Write معقدة: في بعض الحالات مثل نظام بيسجل قراءات حساسات على فترات زمنية متفرقة ، أو كان عندي بقالة بتخزن البضاعة الداخلة بشكل مختلف بناءا على نوع أصناف البضاعة ، أو أي حالة بكون محتاج فيها للأريحية في عمليات ال Wrtie في نظامي. بكون بهالحالة خيار ال Non-relational Database هو الأنسب لكل الأسباب اللي اتكلمنا عنها.
و طبعا بيفضل الخيارين مناسبين بمعظم اذا ما كان كل التطبيقات ، لحد ما نوصل لمرحلة تطبيقية معينة بتجبرنا ناخد أحد الخيارين بشكل قسري لعدم مناسبة الخيار الثاني ، و عامل آخر مهم هو مدى التمكن من نوع ال Database اللي بدنا نستخدمو ، و هو الشي اللي بينطبق عليه موضوع المقال الثاني (How to choose your Tech-Stack).
و هيك بنكون ختمنا المقال الثالث بسلسلتنا ، Database Design ✨
