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

كما يقول العنوان، كان هدفي هو ترحيل قاعدة بيانات SQLite إلى MySQL، وهو الأمر الذي نشأ من مهمة في موضوع قاعدة البيانات الذي أدرسه.

قاعدة البيانات التي اخترتها تنتمي إلى اللعبة SQL Murder Mystery. هذه اللعبة، التي تم إنشاؤها لتعليم مهارات SQL بطريقة ممتعة، متاحة على هذا الرابط، حيث يمكنك تنزيل قاعدة البيانات المقدمة من قبل مطوريها.

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

كانت خطوتي الأولى في هذا التحدي هي التحقق مما إذا كان بإمكاني استخدام متصفح DB لـ SQLite لتصدير قاعدة البيانات بتنسيق متوافق مع MySQL Workbench. على الرغم من أنني تمكنت من إنشاء برنامج نصي SQL من متصفح DB، إلا أن استيراده إلى Workbench أدى إلى العديد من المشكلات، خاصة بناء الجملة وتكامل البيانات، بالإضافة إلى تعقيد إدارة مثل هذا الملف الكبير.

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

كانت خطوتي التالية هي استخدام وظيفة sqlite3 لتصدير برنامج نصي SQL من خلال المحطة الطرفية (لينكس).

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

مع استنفاد كلا النهجين، أخذت لحظة للتفكير في البدائل الأخرى وتقييمها. لقد اعتبرت أن بايثون يمكن أن تكون أداة فعالة لهذا الترحيل، نظرًا لدعمها لكل من SQLite وMySQL، وبدأت في تصميم خوارزمية لأتمتة العملية.

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

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

رسم الخرائط الارتباطية للكائنات (ORM) هو أسلوب يستخدم في البرمجة لتحويل البيانات بين أنظمة الكتابة غير المتوافقة في لغات البرمجة الموجهة للكائنات. في سياق قواعد البيانات، يسمح لك ORM بالتفاعل مع قواعد البيانات العلائقية من خلال الكائنات بدلاً من استخدام استعلامات SQL مباشرة. وهذا يوفر طريقة أكثر سهولة وكفاءة للتعامل مع البيانات.

في حالتي استخدمت SQLAlchemy لتنفيذ تطوير الخوارزمية في بايثون، وتحليل النتائج وجدت النقاط الرئيسية التالية.

• فئات مثل الجداول:
  • كل فئة تحددها (مثل Crime_scene_report، drivers_license، وما إلى ذلك) تتوافق مع جدول في قاعدة البيانات. تمثل سمات الفئة أعمدة الجدول.
• المثيلات كصفوف:
  • يمثل كل مثيل لفئة صفًا في الجدول المقابل. عند الاستعلام عن بيانات من SQLite، تحصل على مثيلات لهذه الفئات، مما يجعل العمل مع البيانات أكثر سهولة وتوجهًا نحو الكائنات.
• عمليات الإدراج والتحديث:
  • يسمح لك استخدام طرق مثل merge() بالعمل على هذه الحالات مباشرة. يمكنك إدراج سجلات جديدة أو تحديث السجلات الموجودة دون الحاجة إلى كتابة استعلامات SQL يدويًا، مما يبسط التعليمات البرمجية ويجعلها أكثر قابلية للقراءة.
• إدارة العلاقات:
  • يتعامل SQLAlchemy تلقائيًا مع العلاقات بين الجداول (على سبيل المثال، من خلال المفاتيح الخارجية) من خلال السمات الموجودة في الفئات، مما يسهل التنقل بين السجلات ذات الصلة.

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

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

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

أضيف... إذا كنت تريد أن تفعل الشيء نفسه، فضع في اعتبارك أن SQLite لا يسمح لك بتعديل الجداول مباشرة، وهو اختلاف كبير آخر مع MySQL.

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

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

آمل أن تكون تجربتي في ترحيل قاعدة البيانات من SQLite إلى MySQL مفيدة وملهمة. يقدم كل تحدٍ فرصة للتعلم والنمو في عالم البرمجة.
شكرا على القراءة وحتى المرة القادمة!