يظهر هذا السؤال في كل عرض تشكيكي تقريبًا قدمته. يشاهد شخص ما بانِي ذكاء اصطناعي ينشئ تطبيقًا يعمل في دقائق قليلة، وسؤاله الحقيقي الأول، بعد أن يزول انطباع "واو، هذا سريع" الأولي، هو نسخة من: حسنًا، لكن هل توجد قاعدة بيانات حقيقية هنا فعلًا، أم أنه زيّفها؟ سؤال منطقي. إليك الأسئلة التي تظهر بترتيب تقريبي، حسب كيفية تطور شكوك الشخص عندما يبدأ بتفحص الأمر.
هل توجد قاعدة بيانات حقيقية، أم أن العرض التجريبي يزيّف الأمر ببيانات عينة فقط؟
هناك بالفعل قاعدة بيانات حقيقية. ما يختلف هو أيّها بالضبط، وهذا الاختلاف هو ما يستحق الفهم قبل بناء أي شيء تنوي الاحتفاظ به. أداة بناء تطبيقات بالذكاء الاصطناعي في مرحلة النموذج الأولي تُحسّن من أجل "شاهد هذا يعمل خلال تسعين ثانية" غالبًا ما تلجأ إلى SQLite — ملف واحد على القرص، بلا إعداد، وقادر تمامًا على تشغيل تطبيق حقيقي لمستخدم واحد. أما أداة تُحسّن من أجل "يجب أن يصمد هذا أمام حركة مرور فعلية ومستأجرين متعددين" فتلجأ إلى Postgres، لأن نموذج قفل الملفات في SQLite يبدأ بالتسبب في مشاكل بمجرد أن تحتاج أكثر من عملية واحدة إلى الكتابة في نفس الوقت. اسأل عن أيّهما تحصل عليه. إنه سؤال منطقي تمامًا يمكن طرحه على صفحة مبيعات أو محادثة دعم، وإذا لم يستطع أحد الإجابة عنه بوضوح، فهذا بحد ذاته يخبرك بشيء.
ما محرك قاعدة البيانات الذي يستخدمه فعليًا؟
Postgres، في المنصات المبنية لأي شيء يتجاوز اللعبة. إنها الإجابة المملة، الصحيحة، والملل هو ما تريده هنا. يمنحك Postgres أمانًا على مستوى الصف بحيث تكون صفوف المستأجر A غير مرئية لاستعلامات المستأجر B حتى لو كان في كود التطبيق خلل، ومفاتيح خارجية حقيقية، ومعاملات حقيقية، وعشرين عامًا من "شخص ما واجه هذه الحالة الحدية بالفعل وأصلحها" وراءه. نمط الفشل المثير للاهتمام ليس "أي لهجة SQL" — بل البانون الذين يبدؤون بـSQLite من أجل السرعة ولا يهاجرون منه أبدًا مع نمو الاستخدام، لأن ترحيل قاعدة بيانات حية عليها مستخدمون عمل غير مبهر يسهل الاستمرار في تأجيله. إذا كنت تقيّم بانيًا لشيء تنوي تشغيله لسنوات، اسأل عمّا يحدث لقاعدة البيانات مع نمو التطبيق بعد مستخدم واحد. الإجابة الصادقة تتضمن مسار ترحيل؛ الإجابة المراوغة تتضمن كلمة "قابل للتوسع" مكررة دون تفاصيل.
هل يمكنني رؤية بياناتي الخاصة، أم أنها محبوسة داخل صندوق أسود؟
يجب أن تستطيع ذلك، نقطة. متصفح جداول، وحدة تحكم استعلامات، زر تصدير — طريقة ما لرؤية الصفوف دون المرور عبر واجهة التطبيق نفسها. هذا سؤال ثقة أكثر منه سؤالًا تقنيًا. بانِي ذكاء اصطناعي يولّد مخططًا لا يمكنك تفحصه يطلب منك الثقة بكود لم تكتبه ولا يمكنك تدقيقه، وهو طلب أكبر بكثير من "ثق بي، زر الواجهة يعمل". الأدوات التي تُحسن هذا الجانب تعامل البيانات الأساسية على أنها ملكك افتراضيًا، لا كتفصيل تنفيذي تحميك منه.
هل يتعامل مع تغييرات المخطط عندما أطلب ميزة جديدة؟
هنا يصبح الأمر صعبًا فعلًا، وهنا يقصّر الكثير من بانِي الذكاء الاصطناعي بصمت. إضافة عمود أمر سهل. أما إضافة عمود، وتعبئة الصفوف الموجودة بقيمة افتراضية منطقية، وتحديث كل استعلام يلامس ذلك الجدول، وفعل ذلك دون فقدان بيانات موجودة بالفعل — فهذا ترحيل، والترحيلات من الأماكن القليلة التي لا يعني فيها "الذكاء الاصطناعي كتب كودًا يترجم" نفس معنى "الذكاء الاصطناعي كتب كودًا آمنًا للتشغيل مقابل بيانات الإنتاج". البانِي الذي يستحق الاستخدام يعامل تغيير المخطط كخطوة قابلة للمراجعة بحد ذاتها، لا كشيء مدمج بصمت في طلب ميزة أكبر. إذا طلبت "أضف تاريخ استحقاق للمهام" وحصلت على فرق يمس الواجهة الأمامية فقط، كن مرتابًا — قاعدة البيانات لم تتلقَّ الرسالة.
هل يُنمذج العلاقات بشكل صحيح، أم يُختزل كل شيء في كتلة JSON واحدة كبيرة؟
كلا النمطين موجود، وأيّهما تحصل عليه يهم أكثر مما يدرك معظم الناس في البداية. المخطط العلائقي — جداول منفصلة للمستخدمين والطلبات وبنود الطلبات، مرتبطة بمفاتيح خارجية — يتيح لك طرح أسئلة لم تتوقعها واجهة التطبيق الأصلية أبدًا: "أي العملاء اشتروا X وY معًا"، "ما معدل الاسترداد لدينا حسب فئة المنتج". أما كتلة JSON واحدة غير مُطبَّعة لكل سجل فأسرع في التوليد ومناسبة لتطبيق بسيط فعلًا، لكنها تحوّل كل طلب مستقبلي بسيط مثل "أضف تقريرًا فقط" إلى إعادة هيكلة كاملة. اطلب رؤية المخطط، لا التطبيق العامل فقط. إذا بدا كل جدول مريبًا يشبه `{ id, data jsonb }`، فأنت أمام بانٍ حسّن من أجل عرض شيء على الشاشة بسرعة وأجّل النمذجة الفعلية للبيانات.
| النمط | ما يبرع فيه | أين ينكسر |
|---|---|---|
| مخطط علائقي مناسب (جداول منفصلة، مفاتيح خارجية) | التقارير، الربط بين الجداول، سلامة البيانات، الميزات المستقبلية التي لم تفكر فيها بعد | وقت توليد أولي أطول قليلًا؛ أصعب على موجّه بسيط أن يصيبه بدقة من المحاولة الأولى |
| كتلة JSON واحدة لكل سجل | سرعة الوصول إلى أول عرض تجريبي، تطبيقات بسيطة أحادية الكيان (أداة تدوين ملاحظات، نموذج أساسي) | أي استعلام يمتد عبر سجلات، أي علاقة، أي تقرير — كلها تتحول إلى حلول بديلة في كود التطبيق بدلًا من SQL |
| هجين (حقول أساسية في أعمدة، إضافات مرنة في عمود jsonb) | تطبيقات ذات بنية أساسية ثابتة مع حقول مخصّصة يحددها المستخدم | يتطلب من الأداة معرفة متى تستخدم أيّ حقل — والنسخة المهملة تضع كل شيء ببساطة في عمود jsonb |
ماذا يحدث إذا تجاوزت حجم البيانات الذي صُمم التطبيق من أجله؟
يعتمد ذلك كليًا على ما إذا كان المحرك الأساسي مصممًا للتزامن من الأصل. هذا هو سؤال SQLite مقابل Postgres مجددًا، بثوب مختلف. تطبيق يعمل على SQLite ويتعامل مع بضع مئات من الصفوف لمستخدم واحد يبدو مطابقًا لتطبيق يعمل على Postgres بنفس الحمل — الفرق يظهر فقط عند إضافة كاتبين متزامنين، أو أعداد أكبر من الصفوف، أو نوع الاستعلامات التحليلية التي تستفيد من الفهرسة وتخطيط الاستعلامات. إذا كان تطبيقك حقًا لمستخدم واحد وحجم بيانات منخفض إلى الأبد، فقد لا يزعجك هذا أبدًا. أما إذا كنت تبني شيئًا تأمل أن يكون له عملاء، فاسأل عن سؤال التوسّع قبل أن تواجه المشكلة، لا بعد أن تعلّمك تذكرة دعم فنية الإجابة.
هل بياناتي معزولة فعلًا عن المستخدمين الآخرين على منصة مشتركة؟
هذا هو السؤال الذي سأُلحّ عليه أكثر من غيره، لأنه غير مرئي حتى يفشل. المنصات متعددة المستأجرين التي تخزّن بيانات الجميع في نفس قاعدة البيانات تحتاج إلى حاجز عزل حقيقي — سياسات أمان على مستوى الصفوف مُطبّقة من قِبل قاعدة البيانات نفسها، وليس مجرد كود تطبيق يتذكر إضافة شرط `WHERE user_id = ?` إلى كل استعلام. الفرق مهم لأن العزل عبر كود التطبيق يفشل بصمت: شرط واحد منسي في نقطة نهاية واحدة، وفجأة يستطيع المستأجر أ رؤية صفوف المستأجر ب. أما العزل المفروض من قاعدة البيانات فيفشل بصوت عالٍ، لأن الاستعلام لا يُعيد شيئًا حتى لو نسي كود التطبيق الشرط. اسأل، تحديدًا، عمّا إذا كان عزل المستأجرين مفروضًا على مستوى قاعدة البيانات أم موكولًا إلى كود التطبيق. معظم من يسأل عن "هل يمكنها التعامل مع قاعدة بيانات حقيقية" يطرحون في الواقع هذا السؤال بالذات دون أن يعرفوا مصطلحاته بعد.
هل يمكنني تصدير كل شيء والرحيل إن أردت؟
يجب أن تتمكن من الحصول على تصدير كامل لبياناتك الفعلية — ليس لقطة شاشة لتطبيقك، ولا ملف PDF لتقرير، بل الصفوف الأساسية بصيغة يمكنك تحميلها في مكان آخر. الأداة التي تجعل هذا صعبًا تخبرك بشيء عن نظرتها للعلاقة معك. النسخة الصادقة من "أداة بناء بالذكاء الاصطناعي" تعني أن المنصة ولّدت الكود والمخطط نيابة عنك؛ لم يكن المقصود أبدًا أن تتوقف البيانات عن كونها ملكك بمجرد وصولها إلى جدول لم تُنشئه بنفسك.
قاعدة البيانات هي الجزء الذي لا يعرضه أحد في العروض التوضيحية، وهذا بالضبط سبب استحقاقه السؤال قبل الاشتراك في أي شيء.
لا شيء من هذا هندسة غريبة. إنها نفس العناية الواجبة التي تطبّقها على أي قرار خاص بخدمة خلفية جاهزة (backend-as-a-service) أو استضافة — الذكاء الاصطناعي فقط يجعل من السهل نسيان السؤال، لأن العرض التوضيحي بارع جدًا في إخفاء البنية التحتية. اسأل عن المحرك المستخدم، واطلب رؤية المخطط، واسأل عن الترحيلات، واسأل عن العزل. إذا كانت الإجابات محددة، فأنت على الأرجح بخير.
