<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Postgresql | The .NET Blog</title><link>https://thedotnetblog.com/ar/tags/postgresql/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ar</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Mon, 20 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ar/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>عمل تحسين أداء PostgreSQL يجب أن يتم حيث تكتب الكود</title><link>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/postgresql-performance-dividend-vscode-azure/</link><pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/postgresql-performance-dividend-vscode-azure/</guid><description>أفضل سير عمل لضبط PostgreSQL ليس لوحات قيادة أكثر، بل حلقات تغذية راجعة أضيق داخل المحرر.</description><content:encoded>&lt;p&gt;المصدر الأصلي: &lt;a href="https://azure.microsoft.com/en-us/blog/the-performance-dividend-optimizing-postgresql-on-azure-directly-in-visual-studio-code/"&gt;The performance dividend: Optimizing PostgreSQL on Azure directly in Visual Studio Code&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;أوافق على الأطروحة الأساسية لهذا التحديث من Azure: العمل على الأداء يفشل أقل من نقص الأدوات وأكثر من السياق المجزأ. معظم الفرق لديها بالفعل مراقبة ومحررات استعلام ولوحات قيادة تشغيلية. ما ينقصهم هو الاستمرارية من الإشارة إلى الفعل.&lt;/p&gt;
&lt;p&gt;اتجاه إضافة PostgreSQL في VS Code مهم لأنها تقصر ذلك المسار. عندما تظهر مقاييس الخادم وخطط الاستعلام وتوصيات المستشار في نفس المكان حيث يحرر المطورون SQL بالفعل، تنتقل الفرق من التشخيص إلى الإصلاح أسرع. يبدو ذلك بديهيًا، لكن في المنظمات الحقيقية هو تحول هيكلي. تبديل السياقات هو حيث تُفقد الملكية.&lt;/p&gt;
&lt;p&gt;إليك الجزء العملي لقادة الهندسة. إذا كنت تريد مكاسب قابلة للقياس، لا تقدم هذه القدرات كإضافات اختيارية لطيفة. اجعلها جزءًا من سير عمل المراجعة:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;اطلب لقطة شاشة أو ملخص لخطة الاستعلام لكل تغيير استعلام غير تافه.&lt;/li&gt;
&lt;li&gt;تتبع أهم توصيات المستشار أسبوعيًا وخصص مالكين، وليس مجرد تنبيهات.&lt;/li&gt;
&lt;li&gt;تعامل مع IntelliSense الواعي بالمخطط وصحة search_path كأدوات وقائية، وليس راحة.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;المقال أيضًا يضع Azure HorizonDB كنظرة مستقبلية مع الحفاظ على Azure Database for PostgreSQL كافتراضي الإنتاج اليوم. هذا هو بالضبط الإطار الصحيح. الفرق تقع في المشاكل عندما تحول حماس التكنولوجيا في مرحلة المعاينة إلى التزامات تشغيلية مبكرًا جدًا. استقرار أولاً، ثم تجارب انتقائية.&lt;/p&gt;
&lt;p&gt;رأيي القوي: ثقافة الأداء هي مشكلة محرر قبل أن تكون مشكلة سحابة. إذا كان الضبط يحدث فقط في المعارك الساخنة وغرف العمليات، فأنت لا تمارس هندسة أداء، بل تمارس استجابة لحوادث أداء. قصة تكامل VS Code تساعد الفرق على التحول لليسار، حيث تعيش الإصلاحات الأرخص.&lt;/p&gt;
&lt;p&gt;تحذير واحد: التوصيات المتكاملة يمكن أن تخلق ثقة زائدة إذا توقفت الفرق عن التحقق من الافتراضات ضد سلوك عبء العمل. الضبط بمساعدة AI وتلميحات المستشار هي مسرعات، وليست بديلاً عن انضباط المقارنة. لا تزال بحاجة إلى خطوط أساس واختبارات تحميل قابلة للتكرار وبوابات انحدار.&lt;/p&gt;
&lt;p&gt;إذا كانت مؤسستك تدير PostgreSQL على Azure على نطاق واسع، الخطوة الصحيحة الآن هي توحيد سير العمل المتكامل هذا، ثم قياس وقت الدورة من اكتشاف المشكلة إلى التخفيف. عائد الأداء حقيقي، لكن فقط إذا جعلته تشغيليًا. وإلا، فهو مجرد عرض ميزة آخر.&lt;/p&gt;
&lt;p&gt;الخلاصة: لا تشترِ مزيدًا من قابلية المراقبة. قلّص المسافة بين الرؤية والتغيير.&lt;/p&gt;</content:encoded></item><item><title>PostgreSQL على Azure في VS Code يدور في جوهره حول تضييق حلقة الأداء</title><link>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/postgresql-azure-vscode-performance-loop/</link><pubDate>Mon, 29 Jun 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ar/news/emiliano-montesdeoca/postgresql-azure-vscode-performance-loop/</guid><description>تجربة PostgreSQL على Azure الأحدث في VS Code مهمة لأنها تقلل المسافة بين المقاييس وإرشادات الضبط وتحليل الاستعلامات وإجراء المطور الفعلي. هذا هو عائد الأداء الحقيقي.</description><content:encoded>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;تمت ترجمة هذه المقالة تلقائيًا. لقراءة الأصل، &lt;a href="https://thedotnetblog.com/ar/news/emiliano-montesdeoca/postgresql-azure-vscode-performance-loop/"&gt;انقر هنا&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;تتزايد تكلفة العمل على أداء قواعد البيانات غالبًا لأن حلقة التغذية الراجعة مجزأة.&lt;/p&gt;
&lt;p&gt;تقع المقاييس في مكان، وخطط الاستعلام في مكان آخر، ونصائح الضبط في مكان ثالث. أما المحرر فمفصول عن كل ذلك.&lt;/p&gt;
&lt;p&gt;ولهذا فإن تجربة PostgreSQL على Azure في VS Code المحدثة تبدو أكثر إثارة للاهتمام مما قد تبدو عليه للوهلة الأولى.&lt;/p&gt;
&lt;h2 id="القيمة-الأساسية-هي-ضغط-الحلقة"&gt;القيمة الأساسية هي ضغط الحلقة&lt;/h2&gt;
&lt;p&gt;أقوى ما في هذا التحديث هو أن التشخيص والإجراء يقتربان من بعضهما:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;مقاييس الخادم داخل المحرر&lt;/li&gt;
&lt;li&gt;توصيات Azure Advisor في سياقها&lt;/li&gt;
&lt;li&gt;رؤية أوضح لخطط الاستعلام&lt;/li&gt;
&lt;li&gt;تحليل مدعوم بالذكاء الاصطناعي&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;هذا يجعل العمل على الأداء أقل تشتتًا، وغالبًا ما يأتي منه مكسب الإنتاجية الحقيقي.&lt;/p&gt;
&lt;h2 id="وجهة-نظري"&gt;وجهة نظري&lt;/h2&gt;
&lt;p&gt;الأمر لا يتعلق فقط بميزات PostgreSQL.&lt;/p&gt;
&lt;p&gt;بل بتقليل المسافة التشغيلية بين رؤية المشكلة والتصرف بناءً عليها. وهذا هو نوع التحسين في الأدوات الذي يؤتي ثماره مع الوقت.&lt;/p&gt;
&lt;p&gt;المقال الأصلي: &lt;a href="https://azure.microsoft.com/en-us/blog/the-performance-dividend-optimizing-postgresql-on-azure-directly-in-visual-studio-code/"&gt;العائد من الأداء: تحسين PostgreSQL على Azure مباشرةً في Visual Studio Code&lt;/a&gt;&lt;/p&gt;</content:encoded></item></channel></rss>