تخيل الفوضى، يمكنك إنشاء قاعدة بيانات مجانية في NeonDB بسعة تخزين تبلغ 0.5 غيغابايت وفكر، "لطيف، سأستخدم طبقة مجانية للاختبار" . ثم، بعد ساعات، تأتي رسالة البريد الإلكتروني القاتلة: "لقد تم استهلاك مساحة التخزين الخاصة بك!". واو، ماذا تقصد؟ لم يكن هناك حتى الوقت لتسخين الكرسي! الجواب؟ لقد استخدمت Prisma ORM الرائع، ومن أجل التحسين، قمت بإجراء عدة عمليات ترحيل على مدار اليوم، فقط قمت بنمذجة المخطط.

دعونا نفهم ما حدث، وبطبيعة الحال، لماذا في بعض الأحيان SQL القديمة الجيدة لا تزال أفضل ألف مرة.

أولاً عليك أن تضع نفسك في سياقها الصحيح. كنت أسجل فئة CrazyStack 124 (المعسكر التدريبي الخاص بـ Node و React). ومن الممكن استخدام postgres أو mongodb بدون ORMs. ومع ذلك، طلب مني أحد الطلاب عبر تطبيق WhatsApp تضمين Prisma في المشروع. مهلا، قررت أن أقوم بالتجربة.

Prisma ORM: بسيط ولكنه مكلف

Prisma هو ذلك الشيء الذي يبدو مثاليًا. "سأقوم بتجريد استعلامات قاعدة البيانات، لتوفير الوقت، هذه هي الضجة الجديدة." ولكن، مفاجأة! لا يوجد غداء مجاني، وقد جاء هذا الرانجو على شكل تخزين محمص. لقد قمت بتشغيل migrates خلال النهار، وكان الأمر ثقيلًا على neondb. ولم يكن حتى مشروعًا ضخمًا.

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

Prisma جيد جدًا، ولكن عندما يتعلق الأمر بالتخزين، فهو يحب بذل كل ما في وسعه:

1. عمليات الترحيل الدائرية : في كل مرة أقوم فيها بإجراء عملية ترحيل، يقوم Prisma بإنشاء عمليات ترحيل جديدة وتخزينها. كل واحد لديه حزمة صغيرة خاصة به من البيانات الوصفية والسجلات والجداول.

2. السجلات التي تتضاعف : لضمان عدم حدوث أي خطأ (أو لجعل حياتك أسهل عندما يحدث ذلك)، يقوم Prisma بتسجيل سجلات مفصلة. لكن هذه السجلات تتراكم، وبما أنني لا أعمل في بنك "غير محدود"، فإنها سرعان ما تصبح مشكلة.

3. التحميل الزائد بالجداول المساعدة: بالإضافة إلى عمليات الترحيل، تقوم Prisma أيضًا بإنشاء جداول إضافية لتتبع أشياء مختلفة، خاصة في قواعد البيانات العلائقية، مثل Postgres.

في النهاية، ما بدا وكأنه أداة سحرية لتبسيط الحياة انتهى به الأمر إلى أكل NeonDB المجانية.

SQL "Na Nail": لماذا الأقل هو الأكثر

وهذا هو المكان الذي يأتي فيه نهج SQL القديم الجيد. نعم، Prisma رائع ويوفر الوقت، لكنه في بعض الأحيان يؤدي إلى تعقيد الأمور. دعونا نتحدث عن مزايا التخلي عن ORM وكتابة استفساراتك يدويًا:

1. السيطرة المطلقة : لا توجد مفاجآت في الفاتورة. أنت تعرف بالضبط ما يفعله كل سطر من التعليمات البرمجية ولن تجد سجلات أو جداول مخفية تشغل مساحتك.

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

3. المزيد من الأداء : عندما يتم تنفيذ Direct SQL بشكل جيد، فإنه يستهلك مساحة وموارد أقل بكثير. إنها مثالية للبنوك الصغيرة مثل NeonDB لأولئك الذين هم من أمثالي.

4. لا توجد أعمال مخفية : لا توجد جداول تم إنشاؤها من البداية أو سجلات المعاملات التي تتراكم. السيطرة لك، ولك وحدك.

معنوي القصة:

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

في بعض الأحيان، تكون لغة SQL "سريعة" هي الطريقة الأكثر أمانًا، مما يتيح لك التحكم الدقيق في ما يدخل إلى قاعدة البيانات. والدرس المستفاد هو: في المرة القادمة، سأفكر بشكل أفضل قبل تشغيل عملية ترحيل تلو الأخرى على بنك بسعة 0.5 غيغابايت.