قاعدة بيانات MySQL

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

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

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

والآن الفخ، فهو يوقع مبرمجين جيدين لا أصحاب الأعمال وحدهم. في MySQL إعداد قديم اسمه utf8، وهو رغم اسمه لا يخزن كل الحروف التي يكتبها الناس فعلًا. ضع رمزًا تعبيريًا في اسم عميل أو في ملاحظة توصيل، فيصل النص مكسورًا أو يرفض الحفظ من أصله، ولذلك فالإعداد الذي تريده هو utf8mb4. وهو يُختار يوم إنشاء الجداول، ومن ثم فتغييره لاحقًا في متجر يعمل ويحوي مليون سطر يعني ليلة طويلة وأنفاسًا محبوسة. ولهذا تضبط لينكي سوفت لنظم المعلومات هذا الإعداد قبل أن يوجد أول جدول في المشروع.

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