تُستخدَم قواعد البيانات العلاقيّة منذ وقت طويل. لقد اكتسبت قواعد البيانات من هذا النوع شُهرة بفضل أنظمة إدارتها التي تستخدم النموذج العلاقيّ بشكل جيّد للغاية، وهو النموذج الذي أثبت نفسه كطريقة رائعة للتعامل مع البيانات وخاصة في التطبيقات ذات المهام الحرجة.
سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (RDBMS) شُهرة واستخدامًا. سنستكشف الفروقات الرئيسيّة بينها من حيث المزايا والأداء الوظيفيّ، وكيفية عملها، ومتى تتفوق إحداها على الأخرى، وذلك من أجل مساعدة المطورين على اختيار نظام إدارة قواعد بيانات علاقية (RDBMS).
أنظمة إدارة قواعد البيانات
قواعد البيانات هي مساحات تخزين مرتبة منطقيًّا لكل الأنواع المختلفة من المعلومات (البيانات). لكل نوع من قواعد البيانات –باستثناء عديمة المخطط– نموذج يقدم هيكلة للبيانات التي يتم التعامل معها. أنظمة إدارة قواعد البيانات هي تطبيقات (أو مكتبات) تدير قواعد البيانات بأشكالها وأحجامها وأنواعها المختلفة.
أنظمة إدارة قواعد البيانات العلاقية
تستخدم أنظمة قواعد البيانات العلاقيّة النموذج العلاقيّ للعمل على البيانات. يشكّل النموذج العلاقيّ المعلومات التي ستُخَزَّن مهما كان نوعها، وذلك بتعريفها ككيانات مترابطة ذات خصائص تتعدى الجداول (أي مخططات).
تتطلب أنظمة إدارة قواعد البيانات من هذا النوع أن تكون البُنى (كالجداول مثلًا) معرّفة لتحوي بيانات وتتعامل معها. لكلّ عمود (مثل الخصائص) في الجداول نوعٌ مختلف من المعلومات (نوع البيانات). يُترجَم كلّ سجلّ في قاعدة البيانات –مُعرّف بمفتاح فريد– إلى صفّ ينتمي إلى جدول، وتكون مجموعة خصائص كل سجل معروضة كأعمدة للجدول. وتكون كلها مرتبطة ببعضها كما هو محدد في النموذج العلاقيّ.
العلاقات وأنواع البيانات
يمكن اعتبار العلاقات مجموعات حسابية تحوي مجموعة من الخصائص التي تشكّل معًا قاعدة البيانات والمعلومات المحفوظة فيها. تسمح هذه الطريقة في التعريف والتجميع لقواعد البيانات العلاقيّة بالعمل بالطريقة التي تعمل بها.
عند تعريف جدول لإدخال سجلات، يجب أن يطابق كلّ عنصر يشكل سجلًّا (كالصفة attribute مثلًا) نوع البيانات المحدّد له (كأن يكون عددًا صحيحًا أو تاريخًا مثلًا). تستخدم أنظمة إدارة قواعد البيانات العلاقيّة أنواعًا مختلفة من البيانات ولا يمكن في العادة تبديل واحدة من هذه الأنواع مكان الأخرى. التعامل مع وعبر قيود –كالتي ذكرناها قبل قليل– شائع مع قواعد البيانات العلاقيّة. في الحقيقة، تشكّل القيودُ مركزَ العلاقات.
ملاحظة: إذا كنت تحتاج للتعامل مع معلومات غير مترابطة إطلاقًا وممثلة عشوائيًّا (كالمستندات مثلًا)، فقد تكون مهتمًّا باستخدام NoSQL (قواعد البيانات عديمة المخططات schema-less).
قواعد بيانات علاقية شائعة وهامة
سنتعرف في هذا المقال على ثلاثة أنواع رئيسيّة وهامّة من أنظمة إدارة قواعد البيانات العلاقيّة مفتوحة المصدر التي ساهمت في تكوين عالم تطوير البرمجيات:
- SQLite: نظام إدارة قواعد بيانات علاقيّة مضمّن وقويّ جدًّا.
- MySQL: نظام إدارة قواعد البيانات العلاقيّة الأشهر والأكثر استخدامًا.
- PostgreSQL: نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر المتوافق مع SQL الأكثر تقدّمًا.
ملاحظة: تقريبًا دائمًا تتيح التطبيقات مفتوحة المصدر حريّة استخدام الطريقة التي تريدها. وفي غالب الأحيان تسمح لك أيضًا إنشاء تفرّع (fork) عن المشروع (وبالتالي استخدام نصوصه البرمجيّة) لإنشاء شيء جديد. إذا كنت مهتمًّا بأنظمة إدارة قواعد البيانات، فقد ترغب بالاطلاع على بعض المشاريع المتفرّعة المبنية على هذه المشاريع الشهيرة، مثل MariaDB.
SQLite
إنّ SQLite مكتبة رائعة تُضمَّن في التطبيقات التي تستخدمها. وكونها قاعدة بيانات قائمة بذاتها ومعتمدة على الملفات. تقدّم SQLite مجموعة رائعة من الأدوات للتعامل مع كل أنواع البيانات بقيود أقلّ بكثير وسهولة مقارنة بقواعد البيانات المستضافة المعتمدة على العمليات (خواديم قواعد البيانات). عندما يستخدم برنامج ما SQLite، يعمل هذا التكامل بنداءات (calls) مباشرة ومؤدية للغرض موجهة لملف يحوي البيانات (كقاعدة بيانات SQLite) بدلًا من التواصل عبر واجهة من نوع ما (كالمنافذ ports والمقابس sockets). هذا يجعل SQLite كفؤة وسريعة للغاية، وقويّة كذلك، وهذا بفضل التقنية التي بنيت عليها هذه المكتبة.
أنواع البيانات التي تدعمها SQLite:
- NULL: قيمة فارغة NULL.
- INTEGER: عدد صحيح ذو إشارة (موجب أو سالب) محفوظ في بايت واحد، 2، 3، 4، 6، أو 8 بايت، وهذا يعتمد على حجم القيمة.
- REAL: قيمة النقطة العائمة (floating point)، مخزنة كرقم نقطة IEEE عائمة ذي 8-بايت.
- TEXT: سلسلة نصيّة مخزنة باستخدام ترميز قاعدة البيانات (UTF-8, UTF-16BE or UTF-16LE).
- BLOB: فقاعة من البيانات، تخزّن كما أدخِلَت تمامًا.
ملاحظة: لمعرفة المزيد عن أنواع بيانات SQLite والعلاقات بين أنواع SQLite، ألقِ نظرة على التوثيق الرسميّ حول الموضوع.
مزايا SQLite:
- معتمدة على الملفات: تتكون قاعدة البيانات بأكملها من ملف واحد على القرص، مما يجعلها محمولة تمامًا.
- مدركة للمعايير: رغم أنها قد تبدو كتطبيق قواعد بيانات "بسيط"، إلّا أن SQLite تستخدم SQL. ورغم أنّها أزالت بعض المزايا ( RIGHT OUTER JOIN أو FOR EACH STATEMENT) إلّا أنها تحوي بداخلها مزايا أخرى إضافيّة.
- ممتازة للتطوير، بل وحتى للاختبار: أثناء مرحلة تطوير التطبيقات، في الغالب يحتاج أغلب الناس لحلّ يمكن تطويعه للطلبات المتعدّدة. لدى SQLite قاعدة مزايا غنيّة، ويمكنها تقديم أكثر مما تحتاجه للتطوير، وبسهولة العمل مع ملف وحيد ومكتبة مرتبطة مبنية على C.
عيوب SQLite:
- لا توفّر إدارة للمستخدمين: تأتي قواعد البيانات المتقدّمة بإدارة للمستخدمين –فمثلًا، فيها اتصالات مُدارة بصلاحيات الوصول إلى قواعد البيانات والجداول–. وبأخذ هدف وطبيعة SQLite بعين الاعتبار (عدم وجود مستوىً عالٍ من تعدّد المستخدمين في ذات الوقت)، لا وجود لهذه الميزة.
- عدم توفر إمكانية التلاعب بها للحصول على أداء أفضل: ونظرًا لطبيعة تصميمها أيضًا، لا يمكن التلاعب بـ SQLite للحصول على قدر كبير من الأداء. المكتبة سهلة الضبط والاستخدام. وبما أنها ليست معقّدة، فلا يمكن تقنيًّا جعلها أكثر أداءًا مما هي عليه، وبشكل يفوق أداءها الحاليّ الرائع.
متى تستخدم SQLite:
- التطبيقات المضمّنة: كلّ التطبيقات التي تحتاج لقابليّة النقل، والتي لا تحتاج لتحجيم، كتطبيقات المستخدم المحلي والوحيد، وتطبيقات الهاتف النقّال أو الألعاب.
- كبديل عن الوصول إلى القرص: في العديد من الحالات، يمكن أن تستفيد التطبيقات التي تحتاج للقراءة من والكتابة إلى الملفات على القرص مباشرة من الانتقال إلى SQLite من أجل المزيد من الوظائف والسهولة اللتان تأتيان من استخدام لغة الاستعلام البنيويّة (Structured Query Language – SQL).
- الاختبار: من التبذير أن تستخدم نسبة كبيرة من التطبيقات عمليّة إضافيّة لاختبار منطقيّة العمل (أي الهدف الرئيسيّ للتطبيق: الوظيفيّة).
متى لا تستخدم SQLite:
- في التطبيقات متعدّدة المستخدمين: إذا كنت تعمل على تطبيق يحتاج فيه العديد من المستخدمين الوصول إلى نفس قاعدة البيانات واستخدامها، فالغالب أنّ مدير قواعد بيانات علاقيّ كامل المزايا (مثل MySQL) خيار أفضل من SQLite.
- في التطبيقات التي تحتاج لقدر كبير من الكتابة: من محدوديّات SQLite عمليات الكتابة. يسمح نظام إدارة قواعد البيانات هذا عملية كتابة واحدة وحيدة أن تتم في وقت محدّد، مما يسمح بقدر محدود من الدفق.
MySQL
تعد MySQL أشهر خوادم قواعد البيانات الكبيرة. وهو منتج مفتوح المصدر غنيّ بالمزايا، ويشغّل الكثير من المواقع والتطبيقات على الإنترنت. من السهل البدء باستخدام MySQL، ولدى المطورين وصول إلى كمّ هائل من المعلومات المتعلقة بقواعد البيانات على الإنترنت.
ملاحظة: يجب أن نذكر أنّه نتيجة لشيوع المُنتَج، فإنّ هناك الكثير من تطبيقات الشركات الأخرى وأدواتها ومكتباتها المضمّنة التي تساعد كثيرًا في الهديد من نواحي العمل مع نظام إدارة قواعد البيانات العلاقيّة هذا.
ورغم عدم محاولتها تطبيق معيار SQL كامل، إلّا أنّ MySQL تقدّم الكثير من الوظائف للمستخدمين. وكخادم SQL قائم بذاته، تتصل التطبيقات بعملية مراقب MySQL (وهو تطبيق يعمل في الخلفية بعيدًا عن مرأى المستخدم، ويشار إليه أحيانًا بعبارة جنيّ أو عفريت) للوصول إلى قواعد البيانات ذاتها على خلاف SQLite.
أنواع البيانات التي تدعمها MySQL:
- TINYINT: عدد صحيح متناهي الصغر.
- SMALLINT: عدد صحيح صغير.
- MEDIUMINT: عدد صحيح متوسّط الحجم.
- INT or INTEGER: عدد صحيح بحجم عاديّ.
- BIGINT: عدد صحيح كبير.
- FLOAT: عدد بفاصلة عائمة صغير أحاديّ الدقّة (single-precision floating-point). لا يمكن إلغاؤه.
- DOUBLE, DOUBLE PRECISION, REAL: عدد بفاصلة عائمة متوسط الحجم مزدوج الدقّة (normal-size/double-precision floating-point). لا يمكن إلغاؤه.
- DECIMAL, NUMERIC: عدد بفاصلة عائمة غير مُحتوىً. لا يمكن إلغاؤه.
- DATE: تاريخ.
- DATETIME: تجميعة من الوقت والتاريخ
- TIMESTAMP: ختم زمني (وقت وتاريخ حدوث حدث ما).
- TIME: وقت.
- YEAR: سنة بهيئة منزلتين أو أربعة منازل (المبدئيّ 4 منازل).
- CHAR: سلسلة نصّيّة ذات طول محدّد يتم دائمًا إكمالها من ناحية اليمين بفراغات إلى الطول المحدّد عند تخزينها.
- VARCHAR: سلسلة نصيّة ذات طول متغيّر.
- TINYBLOB, TINYTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 255 (أي 2^8 – 1) محرفًا.
- BLOB, TEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 65535 (أي 2^16 – 1) محرفًا.
- MEDIUMBLOB, MEDIUMTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 16777215 (أي 2^24 - 1) محرفًا.
- LONGBLOB, LONGTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 4294967295 (أي 2^32 - 1) محرفًا.
- ENUM: تِعداد.
- SET: مجموعة.
مزايا MySQL
-
سهلة الاستخدام:
يمكن تثبيت MySQL بسهولة شديدة. أدوات الأطراف الخارجية (third-party)، بما فيها المرئيّة (أي الواجهات الرسوميّة) تجعل البدء مع قواعد البيانات سهلًا للغاية.
-
غنيّة بالمزايا:
تدعم MySQL الكثير من وظائف SQL المتوقّع وجودها في أنظمة إدارة قواعد البيانات العلاقيّة، سواء بطريقة مباشرة أو غير مباشرة.
-
آمنة:
الكثير من مزايا الأمن وبعضها متقدّم مبنيّة في MySQL.
-
قويّة وقابلة للتحجيم:
يمكن لـMySQL التعامل مع الكثير من البيانات، ويمكنها أيضًا استخدامها على نطاق واسع إذا احتاج الأمر.
-
سريعة:
التخليّ عن بعض المعايير سمح لـ MySQL بالعمل بكفاءة عالية وبطريقة سلسة، مما أكسبها سرعة عالية.
عيوب MySQL
-
المحدوديّات المعروفة:
من حيث التصميم، لا تنوي MySQL عمل كلّ شيء، وتأتي بمحدوديّات وظيفيّة قد تتطلبها بعض التطبيقات المتقدّمة جدًّا من الناحية الفنيّة.
-
القضايا المتعلّقة بالمتانة:
الطريقة التي يتم التعامل فيها مع بعض الوظائف في MySQL (كالمراجع، والتبادلات، والتدقيق، وغيرها) تجعلها أقل متانة بقليل من بعض أنظمة إدارة قواعد البيانات العلاقيّة الأخرى.
-
بطء تطويرها:
رغم أنّ MySQL ما زالت من الناحية الفنيّة منتجًا مفتوح المصدر، إلّا أنّ هناك انتقادات تتعلق بعمليّة تطويرها منذ الاستحواذ عليها. ولكن علينا التنويه إلى أنّ هناك قواعد بيانات مبنيّة على MySQL ومتكاملة معها تمامًا تضيف مزايا على تثبيت MySQL القياسيّ (مثل MariaDB).
متى تستخدم MySQL
-
العمليّات الموزّعة:
عندما تحتاج لأكثر مما تتيحه SQLite، فإنّ تضمين MySQL في قائمة التطوير لديك – كذلك بالأمر بالنسبة لتضمين أيّ خادم قواعد بيانات مستقل – يقدّم لك الكثير من الحريّة في العمل إلى جانب بعض المزايا المتقدّمة.
-
الأمان العالي:
مزايا MySQL الأمنيّة تقدّم حماية يُعتمد عليها للوصول إلى البيانات (واستخدامها) بطريقة بسيطة.
-
المواقع وتطبيقات الوِب:
يمكن للأغلبية العُظمى من المواقع (وتطبيقات الوِب) العمل ببساطة مع MySQL رغم القيود. هذه الأداة المرنة والتي يمكن تحجيمها إلى حدّ ما سهلةُ الاستخدام والإدارة؛ وهذا مفيدٌ جدًّا على المدى البعيد.
-
الحلول الخاصّة:
إذا كنت تعمل على حلول محدّدة جدًّا ومخصّصة للغاية، يمكن لـMySQL العمل ضمن احتياجاتك بسهولة، وذلك بفضل إعدادات الضبط الغنيّة فيها وأوضاع العمل.
متى لا تستخدم MySQL
-
التوافقيّة مع SQL:
بما أنّ MySQL لا تطبّق (ولا تسعى لتطبيق) معيار SQL بأكمله، فإنّ هذه الأداة ليست متوافقة بالكامل مع SQL. إذا كنت قد تحتاج التكامل مع أنظمة إدارة قواعد بيانات علاقيّة كهذه، فإنّ الانتقال من MySQL لن يكون سهلًا.
-
التعدّدية Concurrency:
رغم أنّ MySQL وبعض محرّكات الحفظ تعمل بأداء جيّد جدًّا في عمليات القراءة، إلا أنّ عمليات القراءة والكتابة متزامنتين قد تكون سيئة.
-
نقص المزايا:
مجدّدًا نقول، اعتمادًا على اختيار محرّك قواعد البيانات، يمكن أن لا تحوي MySQL على بعض المزايا، كالبحث في النصوص الكاملة.
PostgreSQL
إنّ PostgreSQL هي نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر الأكثر تقدّمًا، والتي هدفها الرئيسيّ أن تكون موافقة للمعايير ويمكن الزيادة عليها. تسعى PostgreSQL (أو Postgres) إلى تبني معايير ANSI/ISO SQL مع مراجعاتها.
تتميّز PostgreSQL عن أنظمة إدارة المحتوى الأخرى بدعمها للتوجه الكيانيّ (object-oriented) المتكامل والمطلوب بشدّة و/أو وظائف قواعد البيانات العلاقيّة، كدعمها الكامل للتبادلات (القيود transactions) التي يعتمد عليها، أي أن تكون مكونة من عناصر غير قابلة للتجزئة، وأن تكون متّسقة ومعزولة وذات قدرات تحمل عالية (Atomicity, Consistency, Isolation, Durability – ACID).
وبسبب التقنية القوية التي تقف خلفها، لدى Postgres قدرات عالية جدًّا في التعامل مع العديد من المهام بكفاءة عالية. يتم الوصول إلى التعدّدية (concurrency) دون قفل قراءة، وذلك بفضل تطبيق تحكم التعدّديّة متعدد الإصدارات (Multiversion Concurrency Control – MVCC). يمكن برمجة الكثير في PostgreSQL، وبالتالي يمكن توسعتها، وذلك باستخدام إجراءات مخصّصة تُدعى "إجراءات التخزين" (store procesures). يُمكن إنشاء هذه الإجراءات لتسهيل تنفيذ عمليات قاعدة البيانات المكررة والمعقدة والتي تكثر الحاجة إليها.
رغم أنّ نظام إدارة قواعد البيانات هذا لا يحظى بشعبيّة MySQL، إلّا أنّ هناك الكثير من أدوات الأطراف الأخرى ومكتباتهم مصمّمة لجعل العمل مع PostgreSQL سهلًا، رغم طبيعته القويّة. يمكن الحصول على PostgreSQL هذه الأيام كحزمة تطبيقات من خلال مدير الحزم المبدئيّ للعديد من أنظمة التشغيل بسهولة.
أنواع البيانات التي تدعمها PostgreSQL
-
bigint:
عدد صحيح من 8-بايت ذو إشارة
-
bigserial:
عدد صحيح من 8-بايت يزداد تلقائيًّا
-
[(bit [(n:
سلسلة ثنائيّة ذات طول محدّد
-
[(bit varying [(n:
سلسلة ثنائيّة متغيرة الأطوال
-
boolean:
متغيّر منطقي (صواب/خطأ)
-
box:
صندوق مستطيل في سطح مستوٍ
-
bytea:
بيانات ثنائيّة ("مصفوفة بايت")
-
[(character varying [(n:
سلسلة محارف (character string) ذات طول متغير
-
[(character [(n:
سلسلة محارف ذات طول ثابت
-
cidr:
عنوان شبكة IPv4 أو IPv6
-
circle:
دائرة في سطح مستوٍ
-
date:
تاريخ في تقويم (السنة، الشهر، اليوم)
-
double precision:
عدد فاصلة عائمة ذو دقّة مزدوجة (8 بايت)
-
inet:
عنوان مضيف IPv4 أو IPv6
-
integer:
عدد صحيح من 4 بايت ذو إشارة
-
[(interval [fields] [(p:
مدة زمنية
-
line:
خط لا نهائيّ في مستوى
-
lseg:
جزء من خطّ مستقيم في مستوى
-
macaddr:
عنوان تحكم بالوصول إلى الوسيط (Media Access Control – MAC)
-
money:
مقدار من المال
-
[(numeric [(p, s:
دقّة رقميّة محدّدة أو يمكن اختيارها
-
path:
مسار هندسيّ على سطح
-
point:
نقطة هندسيّة على سطح
-
polygon:
شكل هندسيّ مغلق على سطح
-
real:
عدد فاصلة عائمة ذي دقّة أحاديّة (4 بايت)
-
smallint:
عدد صحيح من 2-بايت ذو إشارة
-
serial:
عدد صحيح من 4 بايت يزداد تلقائيًّا
-
text:
سلسلة محارف ذات طول متغيّر
-
[time [(p)] [without time zone:
وقت في اليوم (دون منطقة زمنية)
-
time [(p)] with time zone:
الوقت من اليوم (مع منطقة زمنية)
-
[timestamp [(p)] [without time zone:
تاريخ ووقت (دون منطقة زمنية)
-
timestamp [(p)] with time zone:
تاريخ ووقت يشمل المنطقة الزمنيّة
-
tsquery:
استعلام بحث نصّيّ
-
tsvector:
مستند بحث نصيّ
-
txid_snapshot:
لَقطَة (transaction) لهويّة التبادل على مستوى المستخدم
-
uuid:
معرّف فريد عالميًّا
-
xml:
بيانات XML
مزايا PostgreSQL
-
نظام إدارة قواعد بيانات مفتوح المصدر موافق لمعايير SQL:
PostgreSQL مفتوح المصدر ومجانيّ، ولكنه نظام إدارة قواعد بيانات علاقيّة قويّ جدًّا.
-
مجتمع قويّ:
PostgreSQL مدعوم من مجتمع خبيرٍ ومخلص يمكن الوصول إليه عبر مواقع الأسئلة والإجابات والقاعدة المعرفيّة طوال الوقت ومجانًا.
-
دعم قويّ من الأطراف الأخرى:
بغض النظر عن المزايا المتقدّمة جدًّا، تُزيّن PostgreSQL العديدُ من الأدوات الجيّدة ومفتوحة المصدر من أطراف أخرى لتصميم وإدارة واستخدام نظام الإدارة هذا.
-
إمكانية التوسعة:
يمكن توسعة PostgreSQL برمجيًّا باستخدام إجراءات مخزّنة، كما يفترض أن يكون الوضع في نظام إدارة قواعد بيانات علاقيّة متقدّم.
-
كيانيّ:
ليس PostgreSQL مجرّد نظام إدارة قواعد بيانات علاقيّة، ولكنه كيانيّ (objective) أيضًا – ويدعم التضمين (nesting)، ومزايا أخرى.
عيوب PostgreSQL
-
الأداء:
للعمليات البسيطة كثيفة القراءة، يمكن أن تكون PostgreSQL مبالغًا فيها، ويمكن أن تبدو أقلّ أداءً من منافساتها، مثل MySQL.
-
الشعبيّة:
نظرًا لطبيعة هذه الأداة، فإنها تقبع في الخلف فيما يتعلق بشعبيتها، رغم كثرة من استخدامها – مما قد يؤثر على سهولة الحصول على دعم.
-
الاستضافة:
نتيجة للعوامل المذكورة أعلاه، يصعب إيجاد مستضيفين أو مقدمي خدمة يعرضون خدمات PostgreSQL مُدارة.
متى تستخدم PostgreSQL
-
صحّة البيانات:
عندما تكون صحّة البيانات وإمكانية التعويل عليها ضرورة حتميّة، ولا يكون هناك عذر إذا حدث خطب ما، فستكون PostgreSQL الخيار الأفضل.
-
الإجراءات المخصّصة المعقّدة:
إذا كنت تتطلّب من قاعدة بياناتك أداء إجراءات مخصّصة، فـPostgreSQL هي الخيار الأفضل، كونه يمكن توسعتها.
-
التكامل:
إذا كان يُحتمل في المستقبل أن تكون هناك حاجة لنقل نظام قاعدة البيانات بأكمله إلى حلّ مملوك (مثل أوراكل)، فستكون PostgreSQL الأكثر توافقًا والأسهل في التعامل معها عند الانتقال.
-
التصاميم المعقّدة:
مقارنة بتطبيقات أنظمة إدارة قواعد البيانات العلاقيّة المجانية ومفتوحة المصدر الأخرى، تقدّم PostgreSQL لتصاميم قواعد البيانات المعقّدة أكبر قدر من الوظائف والإمكانات دون التفريط بالأمور الأخرى.
متى لا تستخدم PostgreSQL
-
السرعة:
إذا كان كلّ ما تطلبه عمليات قراءة سريعة، فليست PostgreSQL الأداة التي عليك استخدامها.
-
سهولة الإعداد:
إذا لم تكن تحتاج لصحّة مطلقة للبيانات، أو للتوافق مع ACID أو التصاميم المعقّدة، فقد تكون PostgreSQL مبالغًا فيها للإعدادات البسيطة.
-
التكرار:
إذا لم تكن مستعدًّا لقضاء الوقت، وبذل الجهد والموارد، فالحصول على التكرار (أو تعدّد النُسَخ) في MySQL قد يكون أسهل لمن ليست لديهم خبرة في إدارة الأنظمة وقواعد البيانات.
ترجمة -وبتصرّف- للمقال: SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems لصاحبه O.S. Tezer.
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.