أين تعيش هذه البيانات؟

🌐 متاح أيضًا بـ28 لغة

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 4 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: ابنِ ما يخصّك: الكائنات المخصصة · التالي: اختر الكائن المناسب

السؤال الذي تجيب عنه هذه الوحدة: قبل أن تُنشئ كائنًا، أين ينبغي أن تعيش هذه البيانات فعلًا: على النواة في Salesforce، أم يُشار إليها حيث توجد أصلًا، أم تُؤرشف؟

دعني أطرح عليك سؤالًا. يصل متطلب جديد إلى مكتبك. ما أول شيء تفعله؟

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

لذا فالقرار المعماري الأول ليس أي كائن. بل أين ينبغي أن تعيش هذه البيانات؟ أصِب في ذلك، ويكاد نوع الكائن يختار نفسه.

على النواة وخارج النواة

أولًا، كلمة سأستخدمها كثيرًا: النواة (core). النواة هي منصة Salesforce التي تعمل عليها مؤسستك: المنصة متعددة المستأجرين التي تقودها البيانات الوصفية من الوحدة 1، حيث تعيش كائنات المبيعات والخدمة من الوحدة 2، وكل كائن مخصص تبنيه في الوحدة 3. عندما أقول إن البيانات على النواة (on core)، أعني أنها مخزنة في مؤسستك، في كائناتها.

ليست كل البيانات تعيش هناك. Data 360 تحتفظ ببياناتها في مخزنها الخاص، خارج كائنات مؤسستك (فهي قريبة من النواة (near-core): تُدار على النواة، وبياناتها مستضافة خارج النواة؛ والمزيد في الفصل 4). ثم هناك كل ما تشغّله شركتك وليس Salesforce على الإطلاق: نظام ERP، والمستودع، ونظام الطلبات، ومنصة الشريك. كل ذلك خارج النواة. تستطيع Salesforce الوصول إليه وعرضه واستخدامه، لكن مؤسستك لا تخزّنه.

على النواة، هناك نوعان من الكائنات يحملان سجلاتك فعلًا: sObjects، القياسية والمخصصة (__c)، وbig objects (__b). وخارج النواة، تصل إلى البيانات عبر الكائنات الخارجية (__x) وأدوات التكامل الأخرى. ضع في ذهنك تلك اللواحق من الوحدة 3؛ فهي تخبرك أين تعيش قطعة من البيانات من اسمها وحده.

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

1. على النواة: تعيش على مكتبك

تُنشأ البيانات وتتغير وتُستخدم في Salesforce كل يوم: الحسابات، والحالات، والفرص، وأوامر العمل. الاحتفاظ بها في sObjects أشبه بالاحتفاظ بها في مقدمة مكتبك. لهذا وُجدت الكائنات القياسية والمخصصة، وتحصل فيها على كل شيء: تخطيطات الصفحات، والمشاركة، والأتمتة، والتقارير، والبحث، والآن ميزات الذكاء الاصطناعي المبنية على نموذج البيانات.

لكن مكتبك ليس مجانيًا. البيانات على النواة تكلّف تخزينًا، محسوبًا بالطريقة التي تحسبه بها Salesforce، سجلًا بسجل لا عمودًا بعمود، والمستندات تُحتسب على تخزين الملفات وحدها. تناولنا الاثنين في الوحدة 2. والكميات الكبيرة من الصور والمستندات الممسوحة مكانها غالبًا خارج النواة، مع احتفاظ Salesforce برابط فقط.

2. مُشار إليها: تعيش في خزانة ملفات شخص آخر

البيانات ملك لنظام آخر (نظام ERP، أو مستودع بيانات، أو منصة طلبات)، ويظل ذلك النظام مصدر الحقيقة. يحتاج المستخدمون إلى رؤيتها في Salesforce، وربما ربطها بسجل، لكن Salesforce لا تحتاج إلى نسختها الخاصة. وستسمع أيضًا من يسمي هذا بيانات افتراضية (virtual): فهي تظهر في Salesforce افتراضيًا، دون أن تُخزَّن هناك أبدًا.

هذه هي الكائنات الخارجية، عبر Salesforce Connect. أحب أن أقول إنها تبدو كالبطة وتمشي كالبطة، لكنها ليست بطة. تظهر كأنها sObject: يمكنك وضعها في تخطيطات الصفحات والقوائم المرتبطة، وربطها بسجلاتك عبر علاقات البحث الخارجية وغير المباشرة. لكن البيانات ليست مخزنة على النواة. في كل مرة تلمسها، تُجري استدعاءً خارجيًا (callout). افتح سجلًا، أو حمّل قائمة مرتبطة، أو شغّل تقريرًا، فتذهب Salesforce وتسأل النظام الآخر. وهذا يعني زمن استجابة، وصفحتك لا تكون متاحة إلا بقدر ما يكون النظام الذي خلفها متاحًا.

يعترض الناس على تكلفة الترخيص، لذا احسبها كما أفعل في الصف. يُرخَّص Connect لكل نقطة نهاية (endpoint)، ونقطة نهاية واحدة يمكن أن تجلب كائنات كثيرة. والآن اسأل كم يكلّف بناء البديل وصيانته: مكوّن مخصص، وشيفرة الاستدعاء خلفه، ومطوّر جاهز للاستدعاء حين يتعطل. غالبًا ما يكون الترخيص أرخص، ويستطيع المسؤولون لديك ضبطه دون كتابة سطر شيفرة واحد. وأين يقصر: البيانات التي يعدّلها مستخدموك طوال اليوم، أو يعتمدون عليها بكثافة في التقارير.

ويمكن الإشارة إلى المستندات أيضًا. إذا كان عقد ما موجودًا أصلًا في SharePoint Online أو OneDrive أو Google Drive أو Box، فإن Files Connect يتيح للمستخدمين الوصول إليه من Salesforce دون نسخه إليها.

Salesforce Connect ليس الطريقة الوحيدة للإشارة إلى البيانات. أحيانًا تكون منطقًا مخصصًا: شيفرة تستدعي النظام الآخر في الوقت الفعلي وتعرض بياناته على الصفحة، دون الاحتفاظ بنسخة. وهذا يمنحك تحكمًا كاملًا، ومسؤولية كاملة عن الاستدعاء والأخطاء والصيانة. ويمكن لـ Data 360 أيضًا أن تُجري الاتحاد (federation) دون نسخ. ولهذا الخيار فصل خاص به (المحاكاة الافتراضية والاتحاد وZero-Copy). أما هنا، فالمقصود هو القرار نفسه: أشِر، ولا تنسخ.

3. مؤرشفة: تذهب إلى السقيفة خلف المبنى

التاريخ، وسجلات التدقيق، والمعاملات القديمة. عليك الاحتفاظ بها، أحيانًا لسنوات، لكن لا أحد تقريبًا يفتحها. وهذا هو الأمر الذي تؤجله الفرق. عندما يخبرني صف أن لديهم كائنًا فيه 50 مليون سجل ويسألون لماذا يؤرشفون، أسألهم بدوري: إذا لم تكن تؤرشف اليوم، فهل ستؤرشف يومًا ما؟ عند 50 مليونًا اليوم، أنت متجه نحو 100 و150 و200 مليون.

هناك سقيفتان. إحداهما على النواة: big objects. فكّر فيها كتخزين البيانات في المرآب. يمكنك تخزين عدد هائل من السجلات، لكن لا يمكنك وضعها في تخطيط صفحة، ولا توجد واجهة مستخدم أو تقارير قياسية، وتستعلم عنها عبر فهرس الـ big object، بالمطابقة التامة أو بالنطاق (Big Objects Best Practices (opens in a new tab)). والأمان يقتصر على أذونات الكائن والحقل، بلا مشاركة على مستوى السجل، والأتمتة لا تعمل عليها. لقد استخدمت Salesforce Connect عشرات المرات، وbig objects مرة أو مرتين فقط. إنها تعمل، لكنها غير مريحة، وقد كتبت نصيبي من الحلول الالتفافية للوصول إلى البيانات. لذا نصيحتي: ابنِ نموذجًا أوليًا قبل أن تقترحها، وخطّط لكيفية عثور الناس على البيانات قبل أن تختارها.

والسقيفة الأخرى خارج النواة: مستودع أو قاعدة بيانات في مكان آخر (التصميم للنطاق الواسع). وغالبًا ما تكون هي السقيفة الأفضل، ولا يلزم أن تكون بعيدة عن الأنظار. فالبيانات المؤرشفة خارج النواة يمكن أن تظل تظهر في التقارير عبر أدوات مثل Tableau، ويمكن أن تظل في متناول Salesforce، عبر Salesforce Connect أو طريقة أخرى لعرضها افتراضيًا، حين يحتاج أحد إلى النظر إلى الوراء.

دعني أحدثك عن مشروع أصبنا فيه هذا من البداية. كان لدى عميل في قطاع التجزئة أكثر من 1,200 موقع. قالوا لي: «لا نُجري سوى مئة موعد في اليوم في المتجر. ليس بالأمر الكبير». ثم أجريت الحساب: مئة في اليوم، ستة أيام في الأسبوع (نحو 305 أيام في السنة)، عبر 1,200 موقع، تعني أكثر من 36 مليون موعد في السنة. ثم ذكروا أن كل زيارة تُنشئ موعدين، أحدهما عند المنضدة الأمامية والآخر لورشة الخلف: أكثر من 73 مليون سجل في السنة. ثم أرادوا تاريخ خمس سنوات: أكثر من 360 مليون سجل، قبل أي نمو. لم نكن قد انطلقنا بعد، وكنت أرى القطار متجهًا مباشرة نحو محطة أحجام البيانات الكبيرة. لذا بُني الأرشيف قبل أن نجمع موعدًا واحدًا: انتقلت المواعيد الأقدم إلى big objects، وعرضت شاشة البحث المواعيد الحالية مع المؤرشفة أسفلها مباشرة. وبعد سنوات، ما زال يعمل جيدًا.

Click to enlarge

التطبيق العملي: Steve Trucking

Steve Trucking هي السيناريو المستمر معنا: شركة عائلية للتوصيل في الميل الأخير، تستلم الأجهزة المنزلية والإلكترونيات من مراكز توزيع كبار تجار التجزئة، ثم توصلها وتركّبها في منازل العملاء. أربعة أنواع من بياناتها، وثلاث إجابات:

البيانات	أين تعيش	لماذا
توصيلات اليوم والطواقم والمواعيد	على النواة	يعمل عليها المرسِلون والطواقم طوال اليوم
تفاصيل طلب تاجر التجزئة	مُشار إليها (أو نسخة مختصرة على النواة)	نظام تاجر التجزئة هو مصدر الحقيقة
تاريخ التوصيلات من ثلاث سنوات مضت	مؤرشفة	محفوظة للمطالبات والاتجاهات؛ ولا أحد تقريبًا يفتحها
صور التوصيلات	خارج النواة، مع رابط	الآلاف يوميًا؛ مخزنة خارج Salesforce مع رابط على التوصيلة

إليك الشيء نفسه كنموذج بيانات. تقع التوصيلة (Delivery) على النواة، حيث يعمل عليها الناس طوال اليوم. وبعد ثلاث سنوات، تنتقل إلى Delivery History، وهو big object: ما زال على النواة، لكنه في السقيفة. ويظهر طلب الشريك ككائن خارجي، __x: تربط Salesforce التوصيلة به، لكن البيانات تبقى في نظام تاجر التجزئة. أما الصور فتعيش خارج النواة كليًا، مع رابط من التوصيلة. نموذج واحد، وثلاثة مساكن.

Click to enlarge

كل مؤسسة حقيقية لديها الثلاثة. والتي تقع في المتاعب هي التي تضع كل شيء على النواة، لأن إنشاء كائن كان الزر الافتراضي.

ما الذي يقرره المعماري هنا

• موطن كل نوع من البيانات، قبل تصميم أي كائن: على النواة، أم مُشار إليها، أم مؤرشفة.
• مصدر الحقيقة. إذا كان نظام آخر يملك البيانات، فلا ينبغي أن تصبح Salesforce بهدوء نسخة رئيسية ثانية.
• مسار الوصول إلى أي شيء خارج النواة. البيانات المُشار إليها تحتاج إلى مصدر متاح وزمن استجابة مقبول؛ والبيانات المؤرشفة تحتاج إلى طريقة يجدها بها الناس.
• نمو التخزين. أجرِ الحساب الآن (السجلات في اليوم، مضروبة في النمو، مضروبة في مدة الاحتفاظ)، لا حين يصل تحذير التخزين.

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

للاستزادة

• Big Objects Best Practices (opens in a new tab)، Salesforce Developers (بالإنجليزية، تم التحقق في 2026-09-25)
• Files Connect FAQ (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-09-25)
• في هذه الدورة: المحاكاة الافتراضية والاتحاد وZero-Copy والتصميم للنطاق الواسع