ضرر الإجراءات المخزنة

في محادثة البودكاست "Zinc Prod" أسقطوا مقالًا حول كيفية نقل بعض الأشخاص كل منطق الأعمال إلى الإجراءات المخزنة في pl / pgsql. وبما أن المقال يحتوي على العديد من المزايا ، فهذا يعني أن هناك أشخاصًا ، وربما حتى الغالبية منهم ، أدركوا بشكل إيجابي إعادة البناء هذه.



لن أنشر أفكاري على طول الشجرة ، لكنني سألقي على الفور مجموعة من عيوب استخدام الإجراءات المخزنة.

سلبيات الإجراءات المخزنة

الإصدار

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

لغة pl / pgsql نفسها

إنها لغة إجرائية قديمة من التسعينيات لم تتطور على الإطلاق. لا OOP أو FP أو أيا كان. بناء الجملة دون أدنى تلميح من السكر النحوي.



على سبيل المثال ، يجب التصريح عن المتغيرات في بداية الإجراء ، في كتلة DECLARE خاصة. هذا ما فعله أجدادنا ، هناك بعض الحنين إلى لغة باسكال في هذا ، ولكن شكرًا ، ليس في عام 2020.



قارن بين وظيفتين تقومان بنفس الشيء في php و pl / pgsql:

CREATE OR REPLACE FUNCTION sum(x int, y int)
    RETURNS int
    LANGUAGE plpgsql
AS $$
DECLARE
    result int;
BEGIN
    result := x + y;
    return result;
END;
$$;

function sum(int $x, int $y): int
{
    $result = $x + $y;
    return $result;
}

حوالي 2-3 مرات خربشة.



أيضًا ، يتم تفسير اللغة ، بدون JIT ، إلخ. (صححني إذا تغير أي شيء في الإصدارات الأخيرة). أولئك. كل شيء بطيء وحزين للغاية. إذا كنت تستخدم نوعًا من التخزين ، فعندئذٍ في SQL أو v8 (مثل جافا سكريبت).

تصحيح

صدقوني ، تصحيح أخطاء كود php أسهل 100500 مرة. لقد قمت للتو بتصحيح شيء ما ومشاهدة النتيجة. يمكنك تراكب الصدى أو رؤية ما يوجد من خلال xdebug مباشرة في IDE.



تصحيح أخطاء الإجراءات المخزنة غير مريح. يجب أن يتم ذلك في pgadmin (من خلال تمكين تمديد خاص). PgAdmin بعيدة كل البعد عن PHPstorm من حيث الراحة.

التسجيل ومعالجة الأخطاء

انسَ أمر json الجميل الذي يسقط أثره من stdout ، ثم إلى graylog والحراسة. ولكي يحدث كل هذا تلقائيًا ، مما يعطي المستخدم خطأ 500 إذا لم يكتشف جهاز التحكم الاستثناء.



في تخزين pl / pgsql ، ستفعل كل شيء يدويًا:



GET DIAGNOSTICS stack = PG_CONTEXT;

RAISE NOTICE E'--- ---\n%', stack;



جمع المقاييس

لا يمكنك ، كما هو الحال في golang ، إضافة نقطة النهاية / metrics ، والتي سيتم امتصاصها بواسطة Prometheus ، حيث تقوم بحشد الأعمال والمقاييس الأخرى للمراقبة. أنا فقط لا أعرف كيف أخرج مع pl / pgsql.

تحجيم

يؤدي تنفيذ الإجراء المخزن إلى إهدار الموارد (مثل وحدة المعالجة المركزية) لخادم قاعدة البيانات. في حالة اللغات الأخرى ، يمكنك نقل المنطق إلى العقد الأخرى.

التبعيات

في php ، يمكنك ، باستخدام مدير حزمة الملحن ، سحب المكتبة المطلوبة من الإنترنت بخطوة واحدة. تمامًا كما هو الحال في js ، سيكون npm ، في Rust سيكون البضائع ، إلخ.



في عالم pl / pgsql ، على المرء أن يعاني. ببساطة لا يوجد مدير تبعية بهذه اللغة.

إطار أعمال

في العالم الحديث ، غالبًا لا تتم كتابة تطبيق الويب من البداية ، ولكن يتم تجميعه على أساس إطار عمل باستخدام مكوناته. على سبيل المثال ، في Laravel لديك توجيه ، طلب التحقق ، محرك القالب ، المصادقة / التفويض ، 100500 مساعد لجميع المناسبات ، إلخ. خارج الصندوق. لكتابة كل شيء يدويًا من الصفر ، بلغة قديمة - لا شكرًا.



سيكون هناك الكثير من الدراجات التي يجب صيانتها لاحقًا.

اختبارات الوحدة

من الصعب حتى تخيل مدى ملاءمة تنظيم اختبارات الوحدة في متاجر pl / pgsql. انا لم اجربها مطلقا من قبل. الرجاء المشاركة في التعليقات.

إعادة بناء التعليمات البرمجية

على الرغم من وجود IDE للعمل مع قاعدة بيانات (Datagrip) ، إلا أن أدوات إعادة البناء تكون أكثر ثراءً للغات الشائعة. جميع أنواع linters ، ونصائح لتبسيط التعليمات البرمجية ، إلخ.



مثال صغير: في تلك الأجزاء من التعليمات البرمجية التي قدمتها في بداية المقالة ، أعطت PHPStorm تلميحًا إلى أن المتغير $resultاختياري ، ويمكنك فقط القيام بذلك ، return $x + $y;



في حالة plpgsql - الصمت.

إيجابيات الإجراءات المخزنة

1. لا يوجد حمل لقيادة البيانات الوسيطة على طول مسار الخلفية- قاعدة البيانات.
2. يتم تخزين خطة الاستعلام مؤقتًا في الإجراءات المخزنة ، والتي يمكن أن توفر بضع مللي ثانية. أولئك. كغلاف فوق استعلام ، في بعض الأحيان يكون من المنطقي القيام بذلك (في حالات نادرة ، وليس على pl / pgsql ، ولكن على sql العاري) ، إذا كان هناك حمل كبير محموم ، ويتم تنفيذ الاستعلام نفسه بسرعة.
3. عندما تكتب امتدادك لـ postgres ، لا يمكنك الاستغناء عن التخزين.
4. عندما تريد إخفاء بعض البيانات لأسباب أمنية ، منح التطبيق حق الوصول إلى مخزن واحد أو اثنين فقط (حالة نادرة).

الاستنتاجات

في رأيي ، هناك حاجة إلى الإجراءات المخزنة فقط في حالات نادرة جدًا جدًا عندما تكون متأكدًا من أنه لا يمكنك الاستغناء عنها على الإطلاق. في حالات أخرى ، لن تؤدي إلا إلى تعقيد حياة المطورين بشكل كبير.



سأفهم ما إذا تم نقل بعض المنطق في المقالة الأصلية إلى SQL ، فيمكن فهم ذلك. لكن لماذا التخزين لغزا.



سأكون سعيدًا إذا كنت تعتقد أنني مخطئ أو إذا كنت تعرف أي مواقف أخرى تتعلق بالإجراءات المخزنة (كل من الإيجابيات والسلبيات) ، واكتب عنها في التعليقات.