اربط قاعدة بيانات بمخطط ويحافظ Entity Enricher على كياناتك المُثراة على هيئة جداول علائقية تملكها: جدول company حقيقي بعمود revenue — وليس ملف تصدير. نزّل لقطة SQL جاهزة للتشغيل مرة واحدة، ثم أبقِ قاعدة بياناتك متقاربة عبر تغذية دلتا تزايدية من عمليات upsert عديمة أثر التكرار.
خزّن مرة واحدة، وأسقِط عند الطلب. تكتب عمليات الإثراء الحالة الراهنة للكيان في طبقة الكيانات؛ وكل قاعدة بيانات مرتبطة هي إسقاط لتلك الحالة، تُسلَّم كلقطة لمرة واحدة إضافةً إلى تدفق فروق تقوم بالإقرار به. تعديل المخطط يكلّف إعادة إسقاط، لا ترحيل بيانات أبدًا.
database_sync: false)؛ أما عمليات إثراء المستخدمين الآخرين فتستمر في التوجيه بشكل طبيعي..sql (الجداول + البيانات) وطبّقها على قاعدة PostgreSQL الخاصة بك. تتضمن الـ DDL فهارس الربط والمفاتيح الأجنبية (تُحذف الصفوف الفرعية وصفوف الربط تعاقبياً عند حذف كيان). يُخبرك ترويسة الملف بمؤشر الفروقات الذي ينبغي الاستئناف منه.لكل نوع كيان مفتاح قاعدة بيانات — وهو مجموعة الأعمدة التي تستخدمها جداولك كفهرس فريد وكهدف لتعارض عمليات الإدراج/التحديث (upsert). عند ربط قاعدة بيانات، تقترح عملية تصنيف بالذكاء الاصطناعي نموذج قاعدة البيانات بالكامل (المفاتيح وأنواع الأعمدة والفهارس والملكية) لتراجعه، مع الرجوع إلى تسلسل بسيط: المعرّف الدلالي للكائن إن وُجد، وإلا حقل شبيه بالمعرّف (id، product_id، …)، وإلا المفاتيح الطبيعية للكائن. وفي جداولك يظهر المعرّف الدلالي كعمود semantic_id — ويبقى الاسم id متاحًا لاستخدامك الخاص. يمكنك تغييرها في أي وقت من تبويب “النموذج” في قاعدة البيانات — وهو تغيير بمستوى الترحيل بعد نشره: أعد تنزيل اللقطة بعد ذلك. ولا يصل أي شيء إلى قاعدة بياناتك حتى يُنشر المخطط من ذلك التبويب (الربط وحده لا يُرسل أي جداول أو صفوف).
مفتاح قاعدة البيانات لا يقبل القيمة الفارغة أبدًا. فالقيمة الفارغة لا تطابق أي صف، لذا بدلًا من تحديث الكيان سيُدرِج نسخة مكررة جديدة عند كل إثراء — ولهذا يُرفض أي إثراء يعود مفتاحه فارغًا بدلًا من حفظه. يُبقي المحرِّر العلمين منفصلين، ويُرفض أي schema يضبط كليهما عند حفظه أو ربط قاعدة بيانات، مع تسمية طريقتي الإصلاح: اجعل الخاصية موجودة دائمًا، أو اجعل مفتاح النوع خاصية أخرى.
عندما يكون مفتاح قاعدة البيانات حقلًا نصيًا مُثرىً بدلًا من معرّف دلالي، فتوقّع أن تكون القيمة المخزَّنة هي إجابة النموذج — لا النص الذي أرسلته. فتعريف شركة باسم Embraer في طلبك لا يثبّت ذلك الحقل: قد يجيب الإثراء بـ Embraer S.A. — تهجئة مصحّحة، أو لاحقة قانونية موسّعة، أو مُميِّز محذوف — وهذه هي القيمة التي تُشكّل مفتاح الصف. لذا قد لا يعثر البحث عن الصف بالقيمة التي أرسلتها عليه (استخدم entity_keys المُعادة مع كل إثراء محفوظ)، كما أن أي تشغيل لاحق يصوغها بصيغة مختلفة يُعدّ مفتاحًا مختلفًا — فيُدرج صفًا ثانيًا بدل تحديث صفك. وهذا أمر متوقّع في أي مفتاح مبني على نص مُثرىً. والحل هو معرّف دلالي على ذلك النوع: إذ تُحَلّ صيغ الاسم المختلفة إلى هوية واحدة ثابتة، فيبقى الصف قائمًا مهما كانت طريقة النموذج في كتابته. فعّله عند توليد المخطط — فإضافته لاحقًا تعني تعديل كل كائن.
تتحول الكائنات المتداخلة داخل المصفوفات إلى جداول خاصة بها مع صفوف ربط تحفظ الترتيب؛ أما كائنات القيم التي لا هوية لها فتبقى مسطّحة ضمن أعمدة الكائن الأصلي. تُستخدم أسماء الخصائص حرفيًا (بين علامتَي اقتباس) — فأسماء أعمدتك هي أسماء خصائص المخطط لديك، ولا تُختصر إلا حيث يتجاوز المسار المتداخل ما يمكن أن يُسمّيه PostgreSQL.
الإسقاط حتمي — يُطابق المخطط ذاته دائماً الجداول والأعمدة ذاتها. تصبح أسماء الخصائص أسماء أعمدة حرفياً (بين علامتَي اقتباس)؛ وتُحوَّل أسماء الأنواع إلى نمط snake_case لتصير أسماء جداول (VideoGame → video_game). والاستثناء الوحيد هو الطول: لا يمكن لـ PostgreSQL أن يحتوي معرّفاً يتجاوز 63 بايت، لذا يختصر المسار العميق التداخل كائناته الأصلية لتلائم الطول (morphological_description_ → morpdesc_) — بالبادئة ذاتها لكل عمود من أعمدة ذلك الكائن، وتُعرض وتُحرَّر في علامة التبويب النموذج قبل الربط. كما يمكن لخاصية أن تُسقط بادئتها بالكامل لتطابق عموداً موجوداً بالفعل في قاعدة بياناتك (product_identifiers.stock_keeping_unit → sku) — عبر مفتاح تبديل الربط بجوار الاسم في علامة التبويب النموذج. يحمل كل جدول عموداً باسم _sync_revision يُستخدم للحفاظ على تقارب عمليات إعادة التشغيل.
| في schema الخاص بك | في قاعدة بياناتك |
|---|---|
| كائن ذو هوية (معرّف دلالي أو مفاتيح) | جدولها الخاص؛ تصبح مفاتيح قاعدة البيانات الفهرس الفريد وهدف الإدراج أو التحديث (upsert) |
| حقل قياسي (سلسلة نصية، رقم، قيمة منطقية) | عمود مُصنّف النوع (TEXT، BIGINT، NUMERIC، BOOLEAN) |
| مجموعة مغلقة (حقل مقيَّد بقائمة من القيم) | عمود TEXT عادي — بلا CHECK وبلا نوع enum في قاعدة البيانات. تُطبَّق القائمة عند إجابة الذكاء الاصطناعي، لذا فإن إضافة قيمة إليها لاحقًا لا تُرحِّل قاعدة بياناتك أبدًا. أضف قيدك الخاص إن أردت — فالمزامنة لا تمسّه أبدًا |
| حقل قابل أو غير قابل للقيم الفارغة | يتحوّل الحقل غير القابل للقيم الفارغة افتراضيًا إلى عمود NOT NULL، مقترنًا ببوابة الجودة أدناه — وفي أشدّ البوابات صرامةً تحصل المراجع المطلوبة على مفاتيح خارجية NOT NULL أيضًا؛ ويمكنك تعطيل هذا الإلزام — عند التسجيل أو لاحقًا: فأي تغيير بعد أول مزامنة يُشحن كترحيل محميّ ضمن التدفّق — لإبقاء كل عمود قابلًا للقيم الفارغة وترك البوابة وحدها تفرض الاكتمال |
| حقل متعدد اللغات | عمود JSONB واحد يحتوي على كل اللغات |
| كائن قيمة مضمّن (بلا هوية) | مُسطَّحة في أعمدة مسبوقة ببادئة (dimensions_width) |
| مصفوفة من كائنات القيمة | جدول فرعي مفهرس على الأصل، مُرتّب، ويُحذف تعاقبيًا عند الحذف |
مصفوفة من الكيانات / علاقة $ref | جدول وصل يربط صفوف المصدر والهدف، مع الحفاظ على الترتيب |
حقل المفتاح (identifying) | فهرس ثانوي لعمليات البحث السريعة |
| فهرس بشكل الاستعلام (قائمة حقول مرتّبة) | فهرس واحد متعدّد الأعمدة لكل بنية معلَنة، مرتَّب على شاكلة استعلام شاشة القائمة الذي يخدمه — الأوجه والمجموعات المغلقة أوّلًا، وعمود الفرز أو النطاق أخيرًا، مع تضمين الحقول متعدّدة اللغات (تُنشَر بنية كهذه مرّة لكل لغة استقبلتها قاعدة بياناتك)؛ تقترحه مرحلة التصنيف مع تعليل، ويُنقَّح في تبويب «النموذج»، وقد يتعدّد لكل كيان |
| حقل بحث (نية الفهرسة) | فهرس ثلاثيات الأحرف (pg_trgm) على النصوص التي تطابقها مربّعات البحث لديك بالأجزاء — لكل لغة وبلا حدّ على الأعمدة متعدّدة اللغات؛ ولا يُستخدم أبدًا على قيمة قائمة منسدلة، إذ مكانها فهرس مصمَّم على شكل الاستعلام (بما في ذلك المتعدّدة اللغات — يُنشَر فهرس كهذا مرّة لكل لغة استقبلتها قاعدة بياناتك)؛ ويُتخطّى (بلا أثر) على النسخ المطابقة التي يعوزها الامتداد إلى أن يثبّته أحد مالكي قاعدة البيانات |
| زوج إحداثيات (خط العرض + خط الطول) | فهرس مكاني واحد على الزوج (GiST الأصلي في PostgreSQL، دون امتداد) — استعلامات نصف القطر وأقرب جار وإطار عرض الخريطة |
| زوج فترة (حد البداية + حد النهاية) | فهرس نطاق واحد على الزوج — استعلامات التداخل و"ما القيمة التي كانت سارية في هذا التاريخ" |
يمكن لقاعدة البيانات أن تُزامن أكثر من مخطط واحد. أنواع الكيانات التي تحمل الاسم نفسه عبر المخططات المرتبطة تُوضع في الجدول نفسه، مدمجةً حسب مفتاح قاعدة البيانات الخاص بها — إذ تُحدّث عمليات الإثراء في كل مخطط أعمدته الخاصة فقط، فتصبح الشركة التي أثراها مخططان صفًّا واحدًا يحمل مجموعتَي الأعمدة معًا. أما الأنواع الفريدة لمخطط ما فتضيف ببساطة جداولها الخاصة، وتُسلَّم عبر دلتا ترحيل تلقائية في التدفق — دون الحاجة إلى إعادة التنزيل.
عند ربط مخطط، تُظهر خطوة مقارنة بدقّة أي الجداول سيُدمج (مع مفاتيحها وأعمدتها المضافة) وأيها جديد؛ فالمخطط الذي يشارك جدولًا يتبنّى مفاتيح قاعدة البيانات الموجودة لذلك الجدول، المعروضة لمراجعتك. وإذا لم تتشارك المخططات في أي شيء، يقترح المسار قاعدة بيانات مخصّصة بدلًا من ذلك. أما إلغاء ربط مخطط فلا يمسّ قاعدة بياناتك أبدًا — إذ تبقى الجداول المُزامَنة.
يترك إلغاء ربط مخطط، أو حذف مزامنة، شيئين خلفهما لدينا: حالة الكيان المخزّنة التي لم يعد يكتب إليها شيء، وخصائص قاعدة البيانات التي يحملها المخطط (مفاتيح قاعدة البيانات وأنواع الأعمدة والفهارس والملكية). يعرض كلا التأكيدين إزالتهما، وذلك فقط للمخططات التي لم تعد مرتبطة بأي قاعدة بيانات على الإطلاق — أما المخطط الذي لا يزال يُزامَن في مكان آخر فيحتفظ بكل شيء. أما المخطط نفسه وسجلات إثرائه وتكاليفه فلا تتأثر أبدًا.
يمتلك المخطط المرتبط عقدًا منشورًا: النسخة التي تستخدمها عمليات الإثراء وقاعدة بياناتك فعليًا. لا يؤثر تعديل المخطط إلا على نسخة عمل — تُطبَّق تغييرات الصياغة تلقائيًا، بينما تنتظر التغييرات البنيوية (الحقول الجديدة، وتغييرات النوع أو المفتاح) حتى تضغط نشر. يعرض النشر معاينةً للتأثير الدقيق ويرسل الترحيل المناسب إلى تغذية الدلتا: تصل الأعمدة الجديدة على هيئة فروق ALTER TABLE، بينما تُنفَّذ التغييرات الأثقل (مفتاح قاعدة بيانات جديد، أو تغيير نوع) كترحيلات محمية على قاعدة بياناتك الخاصة — وإذا منعتها البيانات (قيمة مفتاح مفقودة أو مكررة)، تتوقف التغذية مؤقتًا مع بيان المشكلة الدقيقة وتعيد المحاولة تلقائيًا بمجرد إصلاحها.
يوجد النشر في علامة التبويب Model الخاصة بقاعدة البيانات (يعرض محرّر سير العمل لافتة تشير إليها ما دام المخطط مرتبطًا). قبل أن تنشر، يعرض لك الجانبين: العقد الذي تعتمده قاعدة بياناتك اليوم، والفرق الذي ستُحدثه نسختك قيد العمل في كل شيء. غير مقتنع بتعديل ما؟ يعيد الرجوع إلى المنشور العقد إلى سابق حاله — وهو قابل للتراجع، وتبقى المسودة التي نحّيتها جانبًا قابلة للاستعادة لمدة 24 ساعة.
تعمل إعادة ربط مخطط جرى تعديله أثناء فصله بالطريقة نفسها: تتذكّر المزامنة ما تملكه قاعدة بياناتك بالفعل وترسل الفرق فقط، إضافةً إلى تحديث لقطة للصفوف المكتوبة في الأثناء. دون أي DROP يدوي إطلاقًا.
يشمل الوعد نفسه ترقياتنا الخاصة. فعندما يحسّن إصدار جديد طريقة تعيين المخططات إلى الجداول، تُرحَّل مزامنتك نيابةً عنك — إذ تصل التغييرات الإضافية في التغذية من تلقاء نفسها. وإذا كانت الترقية ستعيد تشكيل جداول تحتفظ بها بالفعل، فإننا لا نمسّ بياناتك دون إشعار أبدًا: يتوقف التسليم مؤقتًا وتطلب منك صفحة Database Sync تطبيقها، مع عرض ما سيتغيّر بالضبط أولًا.
الإثراء متعدد اللغات هنا أيضًا من الدرجة الأولى: تصل القيم المُترجَمة على هيئة أعمدة JSONB تحمل كل لغة من لغات الإثراء — {"en": "Headache", "fr": "Céphalée"} — بحيث تخدم قاعدة بيانات واحدة جميع لغاتك في آنٍ واحد. اختر لغةً مباشرةً في استعلاماتك (name->>'fr')، وتحمل حمولات الدلتا بصيغة JSON الكائنات نفسها المفهرسة حسب اللغة.
تجيب كل قاعدة بيانات عن سؤال واحد عند التسجيل: عندما يعود الإثراء بـفجوات — حقول غير قابلة للقيم الفارغة لم تُملأ — فماذا يُكتب؟ الإجابات الثلاث تشكّل سُلّمًا. لا شيء: فجوة واحدة في أي موضع، بما في ذلك داخل كائن متداخل، ويُرفض الكيان. الكيان دون أبنائه غير المكتملين (الوضع الافتراضي): يجب أن يكون صف الكيان نفسه مكتملًا، أما الابن المعطوب فيُتخطّى ويُبلَّغ عنه بدل أن يُغرق الإثراء بأكمله. كل شيء: تُسجَّل الفجوات كقيم NULL ولا يُرفض شيء — لكن حالة الكيان تخضع لقاعدة الكتابة الأخيرة هي الغالبة، فأحدث إثراء هو الصف، ومن ثمّ يمحو تشغيل جزئي لاحق ما ملأه تشغيل سابق. وهذا المحو تحديدًا هو ما وُجدت الدرجتان الصارمتان لمنعه.
عمليات الإثراء التي لا تجتاز البوابة تُحفظ مع ذلك كسجلات، وتُطلق خطاف record.created — مع ضبط database.saved على false — مبيّنةً لك بالضبط أي الحقول المطلوبة كانت ناقصة — حتى لا تختفي البيانات غير المكتملة بصمت. كما يوضّح كل حقل ناقص ما إذا كان النموذج قد صرّح بأنه غير معروف أم أنه أغفله فحسب: الحالة الأولى تستدعي نموذجًا أقوى أو بحثًا على الويب أو مستندًا مصدريًا، والثانية تستدعي مراجعة المخطط أو المدخلات. وحدها حقول مفتاح قاعدة البيانات مطلوبة دائمًا: فأي إثراء تنقصه قيمة مفتاح يُرفض مهما كانت الدرجة.
في الدرجات الصارمة، يعكس مربع اختيار العقد نفسه داخل قاعدة بياناتك على هيئة أعمدة NOT NULL لكل حقل دائم الحضور. وفي أشدّ الدرجات صرامةً تُقيَّد كذلك المفاتيح الخارجية للمراجع المطلوبة — فلا يمكن لأي صف مقبول أن يفتقر إليها. أما في وضع تخطّي الأبناء غير المكتملين فتبقى قابلة للقيم الفارغة عن قصد: فعنصر القائمة الذي تنقصه قيمة خاصة به يُسقَط، والمرجع المشترك واحد-إلى-واحد الذي يكون هدفه غير مكتمل (الملعب الذي لا يعرف أحد سنة افتتاحه) يُفصَل — فلا يُكتب ذلك الهدف ولا يُحدَّث، ويرتبط الصف المحفوظ بلا شيء هناك، ما يكتب NULL في تلك الأعمدة المفتاحية الخارجية بالذات. وكلتا الحالتين يُبلَّغ عنهما في استجابة الإثراء، كما أن الفجوات في الحقول العليا تؤدي دائمًا إلى الرفض. وتغيير السياسة بعد أول مزامنة ليس عملًا ضائعًا أبدًا: فهو يُشحن كترحيل محميّ ضمن التدفّق، مُتحقَّقًا منه مقابل الصفوف الموجودة فعلًا في قاعدة بياناتك.
تلتقط بوّابة ثانية الهويات المكرَّرة: عندما يؤول عنصران من القائمة نفسها إلى مفتاح قاعدة البيانات نفسه — نموذج يبتكر معرّفًا واحدًا لشركتين مختلفتين، أو مفتاح لا يميّز بينهما — لا يمكن أن يوجد سوى صفّ واحد، فيُكتب الأخير وتُسقَط السابقة، وفق القاعدة نفسها المعتمدة في كل مكان: الكتابة الأخيرة هي الفائزة. ويُبلَّغ عن كل تصادم مع القيم المعرِّفة للعنصرين وحكمٍ عليه: الإسقاط المكرَّر كرّر القيم نفسها ولم يفقد شيئًا، أمّا الإسقاط المتعارض ففقد القيم التي يذكرها — فإمّا أن النموذج كرّر الشيء نفسه بقيم مشوّشة، وإمّا أنهما شيئان مختلفان ويحتاج المفتاح إلى خاصية مميِّزة (منطقة أو سنة أو إصدار). وتبقى القائمة محفوظة في السجل، فتظلّ الكتابة الجزئية تُخبر بما فقدته بعد اختفاء الاستجابة بوقت طويل.
أمر ينبغي معرفته قبل إعادة الإثراء: بالنسبة إلى قائمة تابعة للعنصر الأب، فإن قائمة أحدث إثراء هي القائمة المعتمدة. أي صف فرعي لا يكرره أحدث ردّ يُحذف من قاعدة بياناتك — وهكذا يصلك الحذف الفعلي، ولا يبلّغ عنه الردّ. ويكتسب هذا أهمية عندما تكون القائمة مما يستدعيه النموذج من ذاكرته لا مما يعدّده صراحةً: اطلب مرتين نظائر عنصر ما أو جوائز شخص ما، فقد يكون الردّ الثاني أقصر، ما يؤدي إلى حذف صفوف كانت صحيحة. احتفظ بسِجلّك الخاص إن كنت بحاجة إلى اتحاد جميع عمليات التشغيل.
تصل عمليات الإثراء إلى قاعدة البيانات المرتبطة من تلقاء نفسها. أما كل ما عدا ذلك — نتيجة رفضتها البوابة قبل أن تُصلح المخطط، أو تشغيل استبعدته عمدًا، أو مخرج تريد مراجعته أو تصحيحه أولًا — فيتم عبر إرسال السجلات إلى قاعدة البيانات: حدِّدها في صفحة المحفوظات، أو استدعِ API من سير عمل.
الرحلة ذهابًا وإيابًا. أجرِ الإثراء مع إيقاف Database Sync، ثم أعد تشكيل النتيجة أو اعتمدها ضمن سير عملك، ثم أرسِلها. يُعاد التحقق مما ترسله مقابل العقد المنشور للمخطط، ويمر عبر بوابة القبول نفسها التي يمر بها الإثراء — فلا يمكن للحقن أبدًا أن يكتب ما عجز الإثراء عن كتابته.
تفصيلان يجدر معرفتهما. إرسال سجل دون تغيير يخزّنه ضمن ذلك السجل. أما إرسال مخرَج معدَّل فينشئ سجلًا جديدًا يشير إلى الأصل، لأن السجلات مسار تدقيق: فهي لا تتغير أبدًا من تحت البيانات التي تستشهد بها، ومن ثم يظل ما تحتفظ به قاعدة بياناتك قابلًا للتتبع دائمًا إلى سجل يحوي تلك القيم بالضبط. كما يستخدم التحقق العقد بصيغته اليوم — فإذا تغيّر المخطط منذ إنتاج السجل، تنبّهك صفحة السجل التاريخي قبل الإرسال.
تعرض صفحة السجل التاريخي أيضًا، لكل سجل، ما إذا كان قد وصل إلى قاعدة البيانات: أُرسل، أو أُرسل جزئيًا، أو رُفض مع بيان السبب. متاح من تطبيق الويب و API و MCP و n8n و Make.
التدفق عبارة عن طابور صارم يعمل بمبدأ «الوارد أولاً يخرج أولاً» لكل قاعدة بيانات: اجلب نافذة (مع إمكانية حجزها، بحيث يُعاد تسليم دفعة أي عامل تعطّل قبل أي بيانات أحدث)، ثم طبّقها، ثم أقرّ باستلامها. وتُرسَل إشعارات Webhook بعد تهدئة — إذ يعيد كل تغيير جديد ضبط مؤقّت فترة السكون، فيُعلَن عن موجة من عمليات الإثراء مرة واحدة، ويحدّ تأخيرٌ أقصى قابل للضبط من مدة الانتظار، بينما يُرسَل الإشعار فوراً عند اكتمال صفحة جلب كاملة. ويتحكّم خياران للتطهير فيما يحتفظ به Entity Enricher: حذف نسخ التغييرات المُسلَّمة عند الإقرار باستلامها، و — بهدف تقليل البيانات — حذف حالة الكيان نفسها بعد أن تستلمها كل قاعدة بيانات مرتبطة بالمخطط. ويقبل كل خيار مهلة اختيارية بالأيام: فتبقى النسخ المُسلَّمة تلك المدة بعد الإقرار (نافذة لإعادة التسليم)، ويُحتفظ بالكيان المُسلَّم إلى أن تمضي تلك المدة دون أي تحديث له، مع عملية تطهير كل ساعة تحذف ما انتهت صلاحيته. لاحظ أن تطهير الحالة هو تقليل للبيانات وليس محواً لها: فسجلات الإثراء تبقى إلى أن تحذفها بنفسك، كما أنه يعطّل الدمج بين عمليات الإثراء للكيانات المُطهَّرة.
تتيح لك نقطة نهاية للتحقق (checksum) لكل جدول التأكد في أي وقت من تطابق نسختك المتماثلة، دون إعادة تنزيل أي شيء.
كل شيء موجود في مكان واحد داخل التطبيق — Database Sync، أسفل السجلّ (History) مباشرةً في الشريط الجانبي: سجّل قاعدة بيانات على أي مخطط (مع مراجعة مفتاح قاعدة البيانات)، اربط المخططات أو ألغِ ربطها، أوقِف مؤقتًا تغذية الإثراء لمخطط مرتبط عبر مفتاح التبديل الخاص به (لا بيانات جديدة ولا إشعارات حتى إعادة التفعيل — تظل منشورات المخطط ترسل DDL الخاص بها، وعمليات الإثراء التي تُنفَّذ أثناء الإيقاف المؤقت لا تصل إلى النسخة المتماثلة إلا عبر إعادة سحب لقطة)، وحرّر خياراته، واعرض نقطة نهاية الـ webhook وأظهِر مفتاح التوقيع الخاص بها، ونزّل اللقطة، وتصفّح الحالة الحالية للكيان، وافحص قائمة انتظار الفروق المعلّقة (للقراءة فقط — لا يُمسّ مؤشر سير عملك أبدًا)، واعرض مخطط علاقات الكيانات للجداول المولَّدة مع مفاتيحها ووصلاتها. وفي المزامنة متعددة قواعد البيانات يمكن للمخطط البياني أن يركّز على مخطط واحد: تُعتَّم الجداول والأعمدة والروابط التي تغذّيها المخططات الأخرى — مع بقائها مرئية في مكانها — لترى بالضبط ما يسهم به كل مخطط في الجداول المشتركة.
عندما تستقر عدة قواعد بيانات على الجهاز نفسه، يُلغي زر مضيفات المزامنة في شريط الأدوات مراسم الاقتران لكل قاعدة على حدة: اقرن ذلك الجهاز مرة واحدة، ثم أسنِد التسجيلات إليه. يستحوذ المضيف على كل تسجيل، وينشئ قاعدة البيانات الفعلية إن لم تكن موجودة، ويبدأ المزامنة — فيصبح تسجيل قاعدة بيانات قرارًا تتخذه هنا، لا جلسة طرفية على الخادم. والاقتران يكون لكل خادم Entity Enricher، فيمكن لجهاز واحد أن يخدم عدة نسخ جنبًا إلى جنب.
الجملة التي ترفضها قاعدة بياناتك — والسبب المعتاد تكرارات سابقة تحت فهرس فريد جديد — لا تُعطّل الطابور خلفها. فتُعزل دفعة ذلك الإثراء، ويستمر التدفق، وتُدرج الدفعة في تبويب الحجر مع الجملة التي رفضتها قاعدة بياناتك. عالج السبب ثم أعد الحقن — وهو ما يعيد إسقاط الكيان من حالته الراهنة بدل إعادة تشغيل جملة قديمة — أو احذفها.
GET /api/databases//changes?since=…&format=sql ثم POST /api/databases//ack.هل تستخدم Supabase؟ توضّح مقارنتنا مع Supabase MCP كيف تحمي قواعد العلاقات والمزامنة في EE كتالوج المنتجات، مع أمثلة JSON ومخطّطات جداول مصغّرة.
لا يعمل أي شيء في المزامنة على خادم قاعدة بياناتك — فكل مسار أعلاه هو مستهلك صادر يتصل بأي DSN تزوّده به. تعمل Azure Database for PostgreSQL أو OVHcloud أو AWS RDS أو Supabase أو أي نسخة مُدارة أخرى تمامًا مثل النسخة المستضافة ذاتيًا: وجّه المستهلك إلى DSN السحابي (عادةً ما يفرض المزوّدون المُدارون TLS، لذا أضِف sslmode=require) ثم طبّق.
--dsn الخاص به إلى النسخة المُدارة.delta_available دالة Azure Function / AWS Lambda / OVHcloud تسحب موجز REST وتنفّذ SQL وتُرسل الإقرار.قاعدتان تُبقيان أي مستهلك مُعدّ يدويًا آمنًا: نفّذ عبارات كل دفعة بالترتيب، ضمن معاملة واحدة، ولا تُرسل الإقرار إلا بعد الالتزام (commit). الدلتا عمليات مُتكافئة (idempotent) ومحمية بالمراجعة، لذا فإن أي تعطّل قبل الإقرار يعني ببساطة إعادة تسليم الدفعة، وتؤول إعادة التطبيق إلى التقارب.
قواعد البيانات متاحة في الخطط المدفوعة (تحدّد الخطة عدد القواعد التي يمكنك تسجيلها). PostgreSQL هي لهجة الإطلاق؛ وتعلن كل قاعدة بيانات عن لهجتها، مع التخطيط لدعم MySQL / MariaDB وSQL Server وOracle.