Drizzle ORM برای توسعه‌دهنده‌ای که می‌خواهد در TypeScript با قرارداد typed و ساختاری نزدیک به SQL کار کند، گزینه‌ای قابل بررسی است. این انتخاب به معنی برتری ثابت بر تمام ORMهای دیگر نیست. ادعای قبلی مقاله دربارهٔ عملکرد سه‌برابری نسبت به Prisma، Query و محیط اندازه‌گیری مشخصی نداشت و حذف شده است. هزینهٔ یک درخواست پایگاه داده به Query، Index، شبکه و حجم نتیجه وابسته است؛ نام کتابخانه تنها بخشی از مسیر را توضیح می‌دهد.
برای تصمیم دربارهٔ ORM، ابتدا نیاز پروژه را بنویسید: کدام پایگاه داده، چه نوع رابطه‌ها، چه فرایند Migration و چه تیمی قرار است آن را نگهداری کند؟ معرفی رسمی Drizzle رویکرد کتابخانه و ابزارهای مرتبط را توضیح می‌دهد. خواندن آن نقطهٔ شروع است، اما جای بررسی جریان واقعی پروژه را نمی‌گیرد. یک مثال سادهٔ دریافت یک رکورد نمی‌تواند دربارهٔ گزارش پیچیده، تراکنش خرید یا مهاجرت دادهٔ بزرگ نتیجه بدهد.
Schema typed چه کمکی می‌کند؟
وقتی ساختار جدول‌ها در TypeScript توصیف می‌شود، editor می‌تواند در ساخت Query به نام فیلد و نوع مقدار کمک کند. این کمک، بعضی اشتباه‌های نوشتاری را پیش از اجرا آشکار می‌کند. اما داده‌ای که از بیرون برنامه می‌آید همچنان نیاز به بررسی دارد. ورودی فرم یا پاسخ یک API فقط با وجود یک type در کد معتبر نمی‌شود. باید قرارداد دریافت و اعتبارسنجی آن مشخص باشد، مخصوصاً وقتی مقدار وارد یک Query یا عملیات تجاری می‌شود.
Type-safety نیز به معنی صحت همهٔ قواعد کسب‌وکار نیست. اگر مقدار قیمت از نظر نوع عدد باشد ولی در دامنهٔ مجاز محصول نباشد، type به‌تنهایی مشکل را نمی‌گیرد. اگر کاربر مالک رکورد نباشد، سازگاری نوع Query مجوز ایجاد نمی‌کند. بهتر است نقش هر کنترل جدا نوشته شود: type برای قرارداد کد، validation برای ورودی و authorization برای دامنهٔ دسترسی. مخلوط کردن این نقش‌ها باعث می‌شود یک لایه مسئول کاری فرض شود که انجام نمی‌دهد.
نزدیک بودن به SQL مسئولیت خواندن Query را نگه می‌دارد
اگر نام‌های جدول و joinها در کد واضح باشند، توسعه‌دهنده راحت‌تر می‌تواند Query را با مدل رابطه‌ای مقایسه کند. اما همین نزدیکی نیاز به فهم SQL را از بین نمی‌برد. باید بدانید join انتخاب‌شده چگونه تعداد رکوردها را تغییر می‌دهد و شرط فیلتر در کدام بخش اعمال می‌شود. یک خروجی typed ممکن است از نظر برنامه قابل استفاده باشد، ولی از نظر داده شامل رکوردهای تکراری یا دامنهٔ اشتباه باشد. کیفیت Query باید مستقل مرور شود.
فرض کنید گزارش فروش به سفارش و آیتم‌های آن متصل می‌شود. اگر جمع مبلغ سفارش بعد از join روی هر آیتم تکرار شود، ممکن است عدد گزارش بیش از مقدار واقعی گردد. این مثال فرضی به یک مشکل عمومی مدل رابطه‌ای اشاره دارد و benchmark Drizzle نیست. انتخاب ORM مشکل را خودبه‌خود حل نمی‌کند. برای هر گزارش، واحد شمارش را بنویسید: سفارش، آیتم یا مشتری. همین تصمیم کوچک از بسیاری از اختلاف‌های ظاهراً عجیب در عددها جلوگیری می‌کند.
Driver بخشی از انتخاب است
Drizzle برای اتصال به محیط‌های مختلف از driverهای مرتبط استفاده می‌کند. پیکربندی یک پایگاه دادهٔ محلی با سرویس راه دور یا محیط محدود Serverless یکسان نیست. راهنمای SQLite در Drizzle گزینه‌های اتصال همان خانواده را توضیح می‌دهد. هنگام انتقال نمونه، package و روش اتصال را با محیط واقعی تطبیق دهید. وجود مثال برای یک driver به معنی یکسان بودن رفتار همهٔ driverها، قابلیت تراکنش یا شیوهٔ نگهداری اتصال نیست.
Connection pooling، محدودیت تعداد اتصال و زمان انتظار، مسئله‌های زیرساختی‌اند. اگر Query سریع باشد ولی برنامه برای دریافت اتصال منتظر بماند، تغییر ORM لزوماً تجربه را اصلاح نمی‌کند. مسیر درخواست را به بخش‌های قابل مشاهده تقسیم کنید: دریافت اتصال، اجرای Query، انتقال نتیجه و پردازش آن. این تفکیک کمک می‌کند هزینهٔ واقعی پیدا شود و تیم به‌جای تعویض ابزار، بخش مرتبط را اصلاح کند. گزارش سرعت باید همین زمینه را حفظ کند.
Migration و Query دو جریان جدا هستند
تعریف Schema در کد به معنی تغییر خودکار و ایمن پایگاه دادهٔ تولید نیست. Migration برنامهٔ تغییر ساختار و گاهی داده را مشخص می‌کند. مرجع Migrationهای Drizzle جریان‌های مختلف را توضیح می‌دهد. تیم باید انتخاب کند چه کسی تغییر را می‌سازد، چه کسی آن را مرور می‌کند و ترتیب انتشار برنامه و پایگاه داده چیست. برای دادهٔ واقعی، یک تغییر کوچک نام ستون ممکن است پیامد مهمی برای نسخهٔ قبلی برنامه داشته باشد.
اگر ستون تازه ابتدا اضافه شود و برنامهٔ جدید بعداً شروع به استفاده کند، مسیر با حذف فوری ستون قدیمی متفاوت است. هم‌زیستی موقت دو نسخه باید در برنامهٔ انتشار دیده شود. دستور تولید Migration فقط بخشی از کار است؛ معنی تغییر و اثر آن بر داده نیاز به مرور دارد. برای عملیات بزرگ، مدت و قفل‌های احتمالی نیز مهم‌اند. این مقاله روش اجرای Migration در محیط تولید ارائه نمی‌کند؛ هدف روشن کردن مسئولیت‌های انتخاب ORM است.
Query پارامتری و مجوز را کنار هم نگه دارید
دادهٔ ورودی نباید با چسباندن رشته‌های نامطمئن به SQL تبدیل شود. API کتابخانه را مطابق قرارداد پارامترگذاری آن استفاده کنید و در کاربرد SQL خام نیز مرز ورودی را حفظ کنید. اما پیشگیری از تزریق SQL به معنی مجاز بودن Query نیست. شرط مربوط به مالکیت داده و دامنهٔ سازمان باید بخشی از عملیات باشد. اگر یک شناسهٔ معتبر به رکورد متعلق به شخص دیگر اشاره کند، Query از نظر نحوی درست است و همچنان باید رد شود.
برای عملیات نوشتن، مسیرهای خطا را در مدل محصول ثبت کنید. تکرار درخواست شبکه ممکن است همان عملیات را دوباره به برنامه برساند. اگر ثبت یک سفارش باید یک بار انجام شود، قرارداد جلوگیری از تکرار نیاز به طراحی دارد. ORM به‌تنهایی معنای «یک بار» را از نام تابع شما استخراج نمی‌کند. Constraintها، تراکنش و کلیدهای تجاری باید با هم بررسی شوند. کیفیت این قرارداد از شباهت API کتابخانه به SQL مهم‌تر است.
کارایی را با Query واقعی مقایسه کنید
مقایسهٔ دو ORM باید شامل عملیات یکسان، دادهٔ مشابه و محیط یکسان باشد. دریافت یک رکورد کوچک با گزارش چند join و مرتب‌سازی سنگین قابل جایگزینی نیست. اگر یکی از نمونه‌ها فقط فیلدهای لازم را می‌گیرد و دیگری همهٔ رکورد را، نتیجه دربارهٔ تفاوت Query هم هست. قبل از نتیجه‌گیری، SQL و حجم پاسخ را کنار هم ببینید. عدد بدون این زمینه ممکن است دلیل اشتباهی برای مهاجرت ایجاد کند.
Index مناسب، انتخاب فیلدهای لازم و پرهیز از درخواست‌های تکراری می‌تواند در نتیجه اثر داشته باشد. برای مسئلهٔ N+1، ابتدا الگوی دریافت را پیدا کنید: آیا برنامه برای هر آیتم یک درخواست دیگر می‌فرستد؟ سپس راه اصلاح متناسب با نیاز را انتخاب کنید. اضافه کردن join بی‌حساب نیز ممکن است حجم نتیجه را بالا ببرد. بهینه‌سازی باید با تعداد داده و شکل مصرف هماهنگ باشد؛ یک قاعدهٔ ثابت برای همهٔ Queryها کافی نیست.
هزینهٔ نگهداری را در تصمیم حساب کنید
تیمی که SQL را خوب می‌شناسد ممکن است از کنترل مستقیم‌تر استقبال کند. تیمی با مدل داده و ابزار متفاوت، نیاز دیگری دارد. این تفاوت به معنی خوب یا بد بودن یکی از تیم‌ها نیست؛ تجربه و قرارداد موجود روی هزینهٔ تغییر اثر دارند. گزینه‌ها را با کارهایی مقایسه کنید که قرار است هر هفته انجام شوند: تغییر Schema، گزارش‌گیری، عیب‌یابی و بررسی خطا. کیفیت editor یا کم بودن فایل‌ها تنها بخش‌هایی از تجربهٔ نگهداری‌اند.
برای شروع بررسی، یک جریان کوچک با رابطهٔ واقعی و یک عملیات نوشتن انتخاب کنید. فهرست ناشناخته‌ها را بنویسید و نتیجه را به همان دامنه محدود نگه دارید. برای طراحی لایهٔ HTTP، راهنمای REST API با Node.js و Express مرتبط است. تصمیم دربارهٔ Drizzle باید به قرارداد پایگاه داده، driver و فرایند تیم متصل باشد؛ از معرفی یک ابزار نمی‌توان آیندهٔ قطعی دسترسی به دیتابیس یا برتری همیشگی کارایی را نتیجه گرفت.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!