drawDB: ارسم مخطّط قاعدة بياناتك في المتصفّح، واحصل على سكربت SQL جاهزاً

قاعدة البيانات ليست جداول متجاورة، بل شبكةٌ من الروابط: جدول الطلبات يشير إلى جدول المستخدمين، وحقلٌ في هذا يقابل مفتاحاً في ذاك، وحذف سجلٍّ في طرفٍ قد يجرّ خلفه سجلّاتٍ في الطرف الآخر. وهذه الشبكة هي ما يصعب الإمساك به في الذهن أو في ملفٍّ نصّيٍّ مليءٍ بأوامر CREATE TABLE. ولهذا صار جمعُ الجداول وعلاقاتها في رسمٍ واحد — يُسمّى مخطّط العلاقات بين الكيانات (Entity Relationship Diagram، ويُختصر ERD) — ممارسةً معتادة قبل بناء القاعدة، ووسيلةً لتوثيقها بعد أن تُبنى.

لكنّ الطريق إلى هذا الرسم ثقيلٌ على نحوٍ لا يتناسب مع بساطته. فبرامج النمذجة المتخصّصة مثل MySQL Workbench برامج سطح مكتب تُنزَّل وتُثبَّت وتُهيَّأ لأجل مهمّةٍ قد لا تتجاوز رسم عشرة صناديق. وأدوات الرسم العامّة مثل draw.io لا تعرف شيئاً عن SQL، فتنتهي المحاولة برسمةٍ أنيقة لا يخرج منها سكربتٌ يُشغَّل. ومن يتجنّب الاثنين يكتب أوامر CREATE TABLE مباشرةً ويبني الشبكة في ذهنه وحده، فلا ينكشف الخلل في التصميم إلا بعد أن تمتلئ الجداول بالبيانات ويصير تعديلها مكلفاً.

يسدّ drawDB هذه الفجوة: صفحةٌ تُفتَح في المتصفّح، تُرسَم فيها الجداول وتُوصَل بينها بالفأرة، فيخرج منها مخطّطٌ مقروء وسكربت SQL جاهزٌ للتشغيل — بلا تثبيتٍ ولا حساب.

ما هو drawDB بالضبط

drawDB محرّرٌ لمخطّطات ERD يعمل داخل المتصفّح. والمخطّط فيه بالصورة المتعارف عليها: كلّ جدول يظهر صندوقاً يحمل اسمه وحقوله وأنواعها، وكلّ علاقة بين جدولين تظهر خطّاً يربط الحقل بالحقل الذي يشير إليه.

تفتح الأداة من موقعها drawdb.app كأيّ صفحة ويب، فتجد المحرّر أمامك جاهزاً بلا تسجيلٍ ولا تنزيل. والمشروع مفتوح المصدر بالكامل تحت رخصة AGPL-3.0، ومستودعه على GitHub تجاوز ثمانيةً وثلاثين ألف نجمة، وهو من أكثر أدوات تصميم قواعد البيانات المفتوحة شعبيةً اليوم. بدأ مشروعاً شخصياً صغيراً ونُشِر مفتوحَ المصدر في أبريل 2024، ثم نما بمساهمات أكثر من مئة مطوّر حتى صارت واجهته متاحةً بأكثر من خمسين لغة، بينها العربية.

اختر لهجة قاعدة البيانات أوّلاً

قبل أن ترسم أيّ جدول، يطلب منك drawDB أن تختار نوع قاعدة البيانات التي تستهدفها: MySQL أو PostgreSQL أو SQLite أو MariaDB أو Microsoft SQL Server أو Oracle SQL (وهذه الأخيرة ما زالت تجريبية)، أو نوعاً عامّاً (Generic) لا يخصّ قاعدةً بعينها.

هذا الاختيار ليس شكلياً، لأنّه يحدّد ما يتاح لك داخل المحرّر. فحين تختار PostgreSQL تظهر لك أنواعها الخاصّة والحقول المصفوفية (arrays) والقوائم المحدَّدة (enums)، وحين تختار MySQL تظهر لك الأعداد غير المُوقَّعة (unsigned). أمّا النوع العامّ فيقدّم مجموعة أنواعٍ محدودة قابلة للنقل. وميزة النوع العامّ أنّك تستطيع تصدير المخطّط الواحد إلى أكثر من لهجة SQL، وثمنه أنّه لا يمنحك خصائص أيّ قاعدةٍ بعينها.

كيف تبني المخطّط عملياً

تضيف جدولاً من الشريط الجانبي أو من شريط الأدوات، فيظهر صندوقاً على اللوحة تسمّيه وتضيف إليه الحقول. ولكلّ حقلٍ تضبط اسمه ونوعه، ثم القيود التي تحكمه: كونه مفتاحاً أساسياً، أو فريد القيمة (unique)، أو غير قابل للقيمة الفارغة (not null)، أو متزايداً تلقائياً (autoincrement). وتستطيع كذلك أن تعطيه قيمةً افتراضية، أو شرط تحقّق (check constraint)، أو تعليقاً يشرح وظيفته.

وإن جعلت أكثر من حقلٍ في الجدول مفتاحاً أساسياً، فهم drawDB أنّك تريد مفتاحاً أساسياً مركّباً (composite primary key) وأخرجه كذلك في سكربت SQL. أمّا الفهارس (indexes) فتُعرَّف على حقلٍ واحد أو على عدّة حقول معاً، ويمكن أن تكون مسمّاةً أو فريدة. وإلى جانبها تستطيع تعريف قيود تفرّد (unique constraints) مسمّاة تمتدّ هي أيضاً على أكثر من حقل.

تُرسَم العلاقة بين جدولين بالسحب: تمسك نقطة الوصل الظاهرة عند الحقل الذي سيحمل المفتاح الأجنبي (foreign key)، وتسحبها إلى الحقل الذي يشير إليه في الجدول الآخر — من posts.user_id إلى users.id مثلاً. ويشترط drawDB أن يكون نوعا الحقلين متوافقين، فلا يسمح بوصل نصٍّ برقم.

وبعد إنشاء العلاقة يستنتج drawDB نوع الارتباط (cardinality) من القيود الموجودة: فحين يكون الحقل المُشار إليه مفتاحاً أساسياً والحقل المشير غير فريد، يجعلها علاقةَ واحدٍ إلى متعدّد (one-to-many)، ويمكنك تعديل هذا الاستنتاج يدوياً إن أردت. وفي تبويب العلاقات تضبط ما يحدث عند حذف السجلّ المُشار إليه أو تحديثه (ON DELETE وON UPDATE). والخيارات خمسة: حذف السجلّات المرتبطة به (Cascade)، أو منع الحذف أصلاً (Restrict)، أو تفريغ قيمة المفتاح الأجنبي (Set null)، أو إعادتها إلى قيمتها الافتراضية (Set default)، أو ترك الأمر بلا إجراء (No action).

أمّا علاقة متعدّد إلى متعدّد (many-to-many) فلا تُرسَم مباشرةً، لأنّها لا توجد بهذه الصورة في قواعد البيانات العلائقية أصلاً. الطريقة الصحيحة أن تنشئ جدول وصلٍ (join table) يحمل مفتاحين أجنبيّين يشيران إلى الجدولين، ثم ترسم علاقةً من كلّ جدولٍ إليه. ويستطيع جدول الوصل هذا أن يحمل حقولاً إضافية تخصّ العلاقة نفسها، مثل تاريخ التسجيل في جدولٍ يربط الطلاب بالمقرّرات.

ولتنظيم اللوحة حين تكبر، يعطيك المحرّر أداتين لا تظهران في سكربت SQL: مناطق الموضوع (subject areas) التي تجمع الجداول المتقاربة داخل إطارٍ مسمّى، والملاحظات (notes) التي تكتب فيها قرار تصميمٍ أو تنبيهاً لمن يقرأ المخطّط بعدك.

ولستَ مضطرّاً للبدء من لوحةٍ فارغة في كلّ مرّة. يأتي drawDB بستّة قوالب (templates) جاهزة لمخطّطاتٍ شائعة — نظام مكتبةٍ يدير الكتب والتصنيفات والحجوزات مثلاً — تنسخ أيّها شئت وتبني عليه أو تستكشف به الأداة. وتستطيع كذلك أن تحفظ أيّ مخطّطٍ صنعته قالباً خاصّاً بك، فيظهر لك في قائمة القوالب كلّما أنشأت مخطّطاً جديداً.

لوحة المشاكل: فحصٌ تلقائي لتصميمك

بينما ترسم، يفحص drawDB مخطّطك ويعرض ما يجده في لوحةٍ جانبية للمشاكل (issues). وفائدتها العملية أنّها تلتقط أخطاء التصميم الشائعة قبل أن تصل إلى قاعدة البيانات الحقيقية: جدولٌ بلا مفتاح أساسي، أو فهرسٌ بلا اسم، أو فهرسٌ لم تُحدَّد أعمدته، أو حقلٌ غير قابل للقيمة الفارغة وقيمته الافتراضية فارغة، أو قيمةٌ افتراضية لا تناسب نوع الحقل.

ولك أن تشدّد هذا الفحص أو تخفّفه عبر وضع التدقيق الصارم (strict mode)، أو تُخفي اللوحة كلّها إن كنت ترسم مسوّدةً سريعة.

في الاتجاه المعاكس: من سكربت SQL إلى مخطّط

الاستعمال الثاني للأداة عكس الأوّل تماماً. فإن كانت لديك قاعدة بيانات قائمة وتريد أن تفهم بنيتها أو توثّقها، فلست مضطرّاً لإعادة رسمها يدوياً: صدّر سكربت بنيتها (DDL) من قاعدة بياناتك — بأمرٍ مثل pg_dump --schema-only في PostgreSQL أو mysqldump --no-data في MySQL — ثم الصقه في نافذة الاستيراد داخل drawDB، فيقرأه ويبني المخطّط منه.

خذ هذا السكربت مثالاً. الصقه في نافذة الاستيراد بعد اختيار PostgreSQL، فيظهر أمامك جدولان مرسومان موصولان بعلاقة:

CREATE TABLE users (
    id         SERIAL PRIMARY KEY,
    email      VARCHAR(255) NOT NULL UNIQUE,
    created_at TIMESTAMPTZ  NOT NULL DEFAULT now()
);

CREATE TABLE posts (
    id        SERIAL PRIMARY KEY,
    user_id   INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title     VARCHAR(200) NOT NULL,
    published BOOLEAN NOT NULL DEFAULT false
);

وما يجري داخلياً أنّ drawDB يمرّر النصّ على مُحلّل SQL (parser) يحوّله إلى شجرة تركيبية (AST) تمثّل معنى الأوامر لا حروفها، ثم يقرأ من هذه الشجرة الجداول والحقول والفهارس والقيود والعلاقات ويحوّلها إلى عناصر في المخطّط. والاستيراد متاح للهجات الستّ المدعومة كلّها، إلى جانب ملفّات drawDB نفسها وصيغة DBML.

ولهذا المسار حدٌّ عمليّ يجب معرفته: المُحلّل ليس من صنع drawDB بل مكتبةٌ خارجية يعتمد عليها (node-sql-parser، ومحلّل منفصل للهجة Oracle). ولذلك يستوعب الاستيراد السكربتات المعتادة، لكنّه قد يتعثّر أمام صياغاتٍ أقلّ شيوعاً — أوامر إنشاء الدوال في PostgreSQL، أو تعريفات القيود المكتوبة بأسلوبٍ نادر، أو أنواع البيانات المصفوفية بصيغتها المختصرة. الحلّ العملي في هذه الحالة أن تنظّف السكربت من الأوامر التي لا تخصّ بنية الجداول قبل لصقه.

التصدير: أكثر من مجرّد SQL

بعد أن يكتمل المخطّط، يخرجه drawDB بصيغٍ عدّة، ولكلٍّ منها استعمالٌ مختلف:

• سكربت SQL بلهجة قاعدة البيانات التي اخترتها، جاهزٌ للتشغيل لإنشاء الجداول والعلاقات.
• صور بصيغة PNG أو JPEG أو SVG أو PDF، لعرض التصميم في مستندٍ أو عرضٍ تقديمي.
• ملفّ drawDB بصيغة JSON أو DDB، وهو النسخة الاحتياطية الكاملة التي تعيد استيرادها لاحقاً بكلّ تفاصيل التخطيط والألوان.
• DBML، وهي لغةٌ نصّية مفتوحة لوصف مخطّطات قواعد البيانات صنعتها شركة Holistics وتقوم عليها أداة dbdiagram.io. وبفضل هذا الدعم تستطيع نقل مخطّطك بين drawDB وأدوات DBML الأخرى.
• Mermaid وMarkdown، وهما الصيغتان الأنفع لتوثيق المشروع: تلصق مخطّط Mermaid في ملفّ README.md على GitHub فيُعرَض رسماً حيّاً داخل الصفحة، فيرى كلّ من يفتح المستودع بنية قاعدة البيانات دون أن يفتح أداةً خارجية.

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

أين تُحفَظ مخطّطاتك؟ وما الذي يضيع إن لم تصدّر

في النسخة المجّانية المفتوحة، لا تُرفَع مخطّطاتك إلى أيّ خادم، بل تُحفَظ داخل متصفّحك أنت في قاعدة بياناتٍ محلّية اسمها IndexedDB (وهي مساحة تخزينٍ يوفّرها المتصفّح للتطبيقات لتحفظ فيها بيانات منظّمة أكبر من مجرّد إعدادات). وتُحفَظ معها القوالب المخصّصة التي تصنعها، بينما تذهب تفضيلات المحرّر إلى التخزين المحلّي (local storage).

لهذا التصميم وجهٌ مريح ووجهٌ خطِر. المريح أنّك تعمل بلا حساب ولا اتّصال بخادم، ولا تغادر بنيةُ قاعدة بياناتك جهازك. والخطِر أنّ هذه البيانات مرتبطة بمتصفّحٍ واحد على جهازٍ واحد: فإن مسحت بيانات الموقع، أو أعدت ضبط المتصفّح، أو انتقلت إلى جهازٍ آخر، اختفت مخطّطاتك ولا سبيل لاستعادتها إن لم تكن قد صدّرت نسخةً منها.

وداخل الجلسة الواحدة أنت في أمان: الحفظ التلقائي (autosave) مفعّلٌ افتراضياً، فتعديلاتك تُكتَب في تخزين المتصفّح أوّلاً بأوّل ولا تضيع بإغلاق التبويب. لكنّ هذا الأمان لا يمتدّ إلى مسح بيانات المتصفّح ولا إلى الانتقال بين الأجهزة.

مشاركة المخطّط عبر رابط

حين تختار «Share» في النسخة المفتوحة، ينشر drawDB نسخةً من مخطّطك بصيغة JSON في GitHub Gist خاصّ ويعطيك رابطاً. ومن يفتح الرابط ينزّل تلك اللقطة ويحصل على نسخةٍ مستقلّة منها في متصفّحه هو.

والمشاركة هنا لقطةٌ ساكنة لا قناة تزامنٍ حيّ: تعديلات الطرف الآخر لا تصلك، وتعديلاتك لا تصله إلّا إن ضغطت «Share» مرّةً أخرى لتحديث اللقطة المنشورة. ولإلغاء المشاركة، تُبطِل اللقطة المنشورة من المحرّر نفسه.

كما يولّد لك حوار المشاركة رابط تضمين (embed) لعرض المخطّط داخل صفحة ويب أخرى، مع خياراتٍ لاختيار السمة الفاتحة أو الداكنة وإخفاء عناصر الواجهة عن المشاهد.

شغّله على جهازك أو خادمك

لأنّ drawDB تطبيق واجهةٍ أماميّة صرف (frontend) لا يحتاج قاعدة بيانات ولا خادم تطبيقات، فاستضافته الذاتية من أبسط ما يكون. تبني صورة Docker من المستودع ثم تشغّلها:

git clone https://github.com/drawdb-io/drawdb
cd drawdb
docker build -t drawdb .
docker run -p 3000:80 drawdb

بعدها تفتح http://localhost:3000 فتجد المحرّر كاملاً يعمل داخل شبكتك. وإن أردت تشغيله للتطوير بدل الحاوية، يكفي npm install ثم npm run dev بعد الاستنساخ.

يبقى استثناءٌ واحد: خاصّية المشاركة عبر Gist تحتاج خادماً وسيطاً صغيراً يتولّى الاتّصال بواجهة GitHub البرمجية (API)، وهو مشروع drawdb-server المنفصل. تشغّله وتضبط عنوانه في متغيّر البيئة VITE_BACKEND_URL، وهذه الخطوة اختيارية تماماً ما لم تكن تحتاج المشاركة.

drawDB Pro: ما الذي يُدفَع مقابله؟

المحرّر المفتوح بكلّ ما سبق مجّانيٌّ بلا حدود ولا حساب. لكنّ المشروع أضاف فوقه طبقةً مدفوعة باسم drawDB Pro تعالج ما لا يستطيع تطبيقٌ يعمل في المتصفّح وحده أن يقدّمه: التخزين السحابي، والعمل الجماعي.

خطّة الفريق تُحاسَب بعدد المقاعد النشطة، فإضافة عضوٍ أو إزالته ترفع عدد المقاعد أو تخفضه، وقد يترتّب على ذلك تعديلٌ تناسبيٌّ فوريّ في قيمة الاشتراك. والدفع يمرّ عبر منصّة Paddle. وهناك خطّة مؤسّسية تضيف الدخول الموحّد (SSO) وسجلّات التدقيق. أمّا الأسعار فمعروضةٌ في صفحة التسعير على الموقع، وتختلف بحسب البلد والعملة.

وإن انتهى الاشتراك أو انتهت الفترة التجريبية، فمخطّطاتك السحابية لا تُحذَف، لكنّ مساحة العمل تصير للقراءة فقط — تفتح المخطّطات وتطالعها ولا تستطيع حفظ تعديلٍ عليها حتى تجدّد.

سجلّ الإصدارات وتوليد سكربتات الترحيل

هذه أهمّ ميزةٍ في الخطّة المدفوعة لمن يعمل على قاعدة بياناتٍ حيّة. تسجّل «نقطة حفظ» (version) لمخطّطك السحابي قبل كلّ تغييرٍ كبير، مع رسالةٍ قصيرة تصف ما أنت مقبلٌ عليه، ثم تستطيع لاحقاً أن تعاين أيّ نقطة حفظٍ سابقة في وضع قراءة، أو تستعيدها فتحلّ محلّ المخطّط الحالي. وهذه النقاط يدويّة بالكامل: لا ينشئ drawDB نقاط حفظٍ تلقائية، ولا يحفظ الحالة الراهنة قبل أن تستبدلها الاستعادة — فسجّل نقطةً لها أوّلاً إن كنت قد ترجع إليها.

وفوق نقاط الحفظ هذه يوفّر drawDB توليد الترحيل (migration)، أي أوامر SQL التي تنقل قاعدة بياناتك من الحالة القديمة إلى الجديدة. فحين تطلب توليد ترحيلٍ من نقطة حفظ، يقارن drawDB بينها وبين النقطة الأقدم منها مباشرةً، ويعطيك ثلاثة أشياء: سكربت up الذي يطبّق التغيير، وسكربت down الذي يتراجع عنه، وفرقاً بصيغة JSON يبيّن ما تغيّر بالضبط — وكلّها قابلة للتنزيل في ملفٍّ مضغوط.

ولهذه الميزة قيدان يجب معرفتهما. الأوّل أنّها ما زالت في طورٍ تجريبي (Beta)، وأنّ المقارنة تقتصر على بنية المخطّط ولا تشمل التخطيط البصري ولا الملاحظات. والثاني أنّ المخطّطات من النوع العامّ (Generic) تُظهِر فرق الـ JSON فقط ولا تولّد سكربت SQL، لأنّ الترحيل لا معنى له بغير لهجةٍ محدّدة. وفي كلّ الأحوال، السكربت المولّد مسوّدةٌ تُراجَع قبل تشغيلها على بياناتٍ حقيقية، خصوصاً في التغييرات التي تحذف أعمدةً أو تحوّل أنواعها.

مساعد الذكاء الاصطناعي

يفتح المساعد بزرّ «Ask AI» داخل المحرّر، فتصف له ما تريده بلغةٍ طبيعية — «أضِف جداول الزبائن والطلبات وعناصر الطلب لـ PostgreSQL، بمفاتيح أساسية من نوع UUID وحقول تدقيقٍ زمنية» — فينفّذ التغيير على اللوحة أمامك. وهو يستطيع إنشاء الجداول وتعديلها وحذفها، وإضافة الأعمدة وتغييرها، وإنشاء العلاقات، وإضافة الملاحظات ومناطق الموضوع. ولا يملك أدواتٍ للتعامل مع القوائم المحدَّدة (enums) ولا الأنواع المركّبة، فهذه تُنشَأ يدوياً.

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

ربط المخطّطات بأدوات البرمجة عبر MCP

توفّر الخطّة المدفوعة خادم MCP (اختصار Model Context Protocol، وهو بروتوكولٌ موحّد تتّصل به أدوات الذكاء الاصطناعي بمصادر بياناتٍ خارجية). فائدته العملية أنّ مساعد البرمجة الذي تستعمله — Claude Desktop أو Cursor أو ما يشبههما — يستطيع أن يقرأ مخطّط قاعدة بياناتك مباشرةً وأنت تكتب الكود، فيولّد استعلاماً أو نموذج بيانات مطابقاً لبنيتك الفعلية بدل أن تشرحها له في كلّ مرّة.

تُنشئ مفتاح API من حسابك، ثم تضيف الخادم إلى إعدادات أداتك:

{
  "mcpServers": {
    "drawdb": {
      "command": "npx",
      "args": ["-y", "@drawdb/mcp"],
      "env": {
        "DRAWDB_API_KEY": "ddb_your_key_here"
      }
    }
  }
}

والخادم للقراءة فقط بحكم تصميمه: يسرد مخطّطاتك ويصف جداولها وحقولها وعلاقاتها، ولا يستطيع إنشاء مخطّطٍ ولا تعديله ولا حذفه. ويشتغل الخادم بوصفه عمليةً محلّية على جهازك، فيحتاج إلى Node.js في نسخة 20 أو أحدث. ولا يصل إلى المخطّطات المحفوظة في متصفّحك، بل إلى السحابية وحدها.

drawDB مقابل البدائل

المشهد مزدحمٌ بأدوات رسم قواعد البيانات، لكنّ الفروق بينها ليست في الشكل بل في نقطة البداية: هل تبدأ من مخطّطٍ في ذهنك، أم من قاعدة بياناتٍ قائمة، أم من نصٍّ تكتبه؟

الفارق الأوضح مع ChartDB أنّه صُمّم للاتجاه المعاكس: يعطيك استعلاماً واحداً تشغّله على قاعدتك فيُخرِج بنيتها بصيغة JSON، تلصقه في الأداة فترسم لك المخطّط. فإن كان همّك فهم قاعدة بياناتٍ قائمة وتوثيقها، فهذا مساره الطبيعي. وإن كان همّك تصميم قاعدةٍ جديدة، فمسار drawDB أسرع.

وأمّا dbdiagram.io فيقوم على فلسفةٍ مختلفة كلّياً: لا ترسم فيه شيئاً، بل تكتب تعريف الجداول بلغة DBML فيرسمها هو لك. وهذا يناسب من يفضّل النصّ ويريد وضع تصميمه تحت إدارة الإصدارات (Git). ولأنّ drawDB يقرأ صيغة DBML ويكتبها، فأنت لست مضطرّاً للاختيار النهائي بينهما.

قيوده الحقيقية

هذه أبرز حدود drawDB كما يصفها مستخدموه:

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

لا يمثّل عناصر قاعدة البيانات كلّها. المخطّط في drawDB يغطّي الجداول والحقول والفهارس والقيود والعلاقات والقوائم المحدَّدة والأنواع المركّبة — ولا يتضمّن العروض (views) ولا الإجراءات المخزّنة (stored procedures) ولا المُشغِّلات (triggers). فإن استوردت سكربتاً يحوي هذه العناصر، تُهمَل ولا تظهر في الرسم.

لا يتّصل بقاعدة بياناتك مباشرةً. لا يوجد في drawDB ربطٌ بقاعدةٍ حيّة لسحب بنيتها منها؛ المسار الوحيد أن تصدّر سكربت الـ DDL بنفسك وتلصقه. وهذا في وجهٍ منه ميزةٌ أمنية — لا تعطي الأداة أيّ بيانات اعتماد — لكنّه خطوةٌ يدوية إضافية في كلّ مرّة.

لا ترتيب تلقائي للعناصر. ليس في الأداة ترتيبٌ تلقائي (auto-layout) يعيد توزيع الجداول توزيعاً مقروءاً، فبعد استيراد سكربتٍ كبير قد تجد نفسك تسحب الجداول يدوياً لتفكّ تشابك خطوط العلاقات.

الترخيص قيدٌ إن أردت البناء فوقه. رخصة AGPL-3.0 تسمح لك بالاستعمال والتعديل والاستضافة الذاتية بحرّية، لكنّها تُلزِم من يقدّم نسخةً معدَّلة كخدمةٍ عبر الشبكة بإتاحة شيفرته المعدَّلة للمستخدمين. وهذا لا يعني المستخدم العادي في شيء، لكنّه يعني من يفكّر في دمج المحرّر داخل منتجٍ تجاريّ مغلق.

خلاصة

قيمة drawDB الحقيقية أنّه يزيل الحاجز بينك وبين تصميم قاعدة بياناتك: لا تثبيت، ولا حساب، ولا اتّصال بقاعدةٍ حيّة — تفتح تبويباً وترسم. وهذه الخفّة نفسها هي مصدر حدوده: المخطّطات الضخمة تُثقِله، والحفظ في المتصفّح يجعل النسخة الاحتياطية مسؤوليّتك وحدك.

والسؤال الأهمّ في المشروع اليوم ليس تقنياً بل يخصّ مساره: فقد بدأ أداةً مجّانية بالكامل، ثم صارت الميزات التي تحوّله من أداة رسمٍ فردية إلى أداة فريق — التخزين السحابي، وسجلّ الإصدارات، وتوليد الترحيلات، والعمل اللحظي — وراء اشتراك. المحرّر المفتوح ما زال كاملاً ومجّانياً ويعمل بلا أيّ خادم، وهذا ما يهمّ أغلب من يفتحه لرسم مخطّطٍ سريع. لكنّ من ينوي بناء سير عملٍ فريقيّ فوقه يحسن به أن يعرف من الآن أين يقع الخطّ الفاصل.

والمحرّر مفتوحٌ للتجربة مباشرةً في المتصفّح، وشيفرته وتوثيقه متاحان للاطّلاع: