مضرات شاخص کامپوزیت

شما به دنبال مستندات میراث هستید. مستندات جدید چند زبانه موجود در https://docs. deepkit. io

کلید اصلی کامپوزیت

کلیدهای اولیه کامپوزیت موجودی را توصیف می کنند که دارای کلیدهای اولیه است که به طور خودکار در یک "کلید اصلی کامپوزیت" ترکیب می شوند. این روش مدل سازی پایگاه داده شما مزایا و معایبی دارد. ما معتقدیم که کلیدهای اصلی کامپوزیت دارای مضرات عملی عظیمی هستند که مزایای آن را توجیه نمی کنند تا جایی که باید آن را یک عمل بد تلقی کند و از این رو باید از آن جلوگیری کرد. DeepKit ORM از کلیدهای اصلی کامپوزیت پشتیبانی نمی کند. در این فصل توضیح می دهیم که چرا و گزینه های دیگر (بهتر) را ذکر می کنیم.

معایب

پیوندها بی اهمیت نیستند ، اگرچه در RDBMS بسیار بهینه شده اند ، اما دائماً پیچیدگی در برنامه هایی هستند که می توانند به راحتی از دست خارج شوند و مشکلات عملکرد را معرفی کنند. عملکرد نه تنها لزوماً از نظر زمان اجرای پرس و جو ، بلکه در زمان توسعه دهنده.

پیوستن

هر عضو در هنگام درگیر شدن چندین زمینه پیچیده تر می شود. در حالی که بسیاری از بانکهای اطلاعاتی بهینه سازی هایی را انجام داده اند تا به خودی خود با چندین زمینه آهسته تر بپردازند ، از طرف توسعه دهنده نیاز دارد که به طور مداوم در مورد آن پیوندها فکر کند ، زیرا به عنوان مثال کلیدها فراموش می کنند می توانند منجر به اشکالات ظریف شوند (زیرا پیوستن با خوشحالی کار می کند بدون اینکه همه را مشخص کندکلیدها) و بنابراین توسعه دهنده باید ساختار کلیدی اصلی کامپوزیت را بشناسد.

فهرست

شاخص ها با چندین زمینه (که کلیدهای اصلی کامپوزیت هستند) در نمایش داده ها از مشکل سفارش میدانی رنج می برند. در حالی که سیستم های پایگاه داده می توانند نمایش داده های خاصی را بهینه کنند ، نوشتن عملیات کارآمد که به درستی از تمام شاخص های تعریف شده استفاده می کنند ، در ساختارهای پیچیده آن سخت است. در یک فهرست چند منظوره (مانند یک کلید اصلی کامپوزیت) ، معمولاً لازم است که زمینه ها را به ترتیب تعریف کند تا در واقع به پایگاه داده اجازه دهد از فهرست استفاده کند. اگر سفارش به درستی داده نشود (به عنوان مثال در بند جایی) ، می تواند به راحتی موتور را به سمت استفاده از شاخص سوق دهد و به جای آن یک اسکن کامل جدول انجام دهد. دانستن اینکه کدام پایگاه داده بهینه سازی نمایش داده ها به چه روش دانش پیشرفته توسعه دهندگان جدید معمولاً ندارند ، اما به محض اینکه با کلیدهای اصلی کامپوزیت کار می کنید ، لازم است تا بیشترین استفاده را از پایگاه داده خود داشته باشید و منابع را هدر ندهید.

مهاجرت

به محض اینکه تصمیم گرفتید که یک نهاد خاص برای شناسایی منحصر به فرد یک ردیف به یک زمینه اضافی نیاز دارد ، منجر به تنظیم هر موجود در پایگاه داده شما می شود که با آن روابط دارد.

بیایید بگوییم که شما به عنوان مثال یک کاربر موجودیت با کلید اصلی کامپوزیت دارید و تصمیم دارید در جداول مختلف یک کلید خارجی برای آن کاربر استفاده کنید ، به عنوان مثال "Audit_log" ، جدول محوری گروه ها و "پست". به محض اینکه کلید اصلی کاربر را تغییر دهید ، تمام آن جداول نیز باید در یک مهاجرت تنظیم شوند.

این امر نه تنها پرونده های مهاجرت را بسیار پیچیده تر می کند بلکه می تواند در هنگام اجرای پرونده های مهاجرت به زمان های کمتری منجر شود زیرا تغییرات طرحواره معمولاً به قفل پایگاه داده کامل یا حداقل قفل جدول نیاز دارد. هرچه جداول بیشتری از تغییر بزرگ مانند تغییر شاخص ایجاد شود ، مهاجرت طولانی تر می شود. همچنین هرچه یک میز بزرگتر باشد ، مهاجرت طولانی تر می شود. در مورد جدول "AUDIT_LOG" از بالا فکر کنید. چنین جداول معمولاً سوابق زیادی دارد (مانند میلیون ها نفر) و شما باید فقط به این دلیل که تصمیم گرفتید از یک کلید اصلی کامپوزیت استفاده کنید و یک زمینه اضافی را به کلید اصلی کاربر اضافه کنید ، آنها را در یک طرح تغییر دهید. بسته به اندازه تمام آن جداول ، باعث می شود تغییرات مهاجرت به طور غیر ضروری گران تر یا در بعضی موارد حتی خیلی گرانتر باشد تا جایی که تغییر اصلی اصلی کاربر از نظر مالی دیگر قابل توجیه نباشد. این معمولاً منجر به راه حل می شود (مانند اضافه کردن یک شاخص منحصر به فرد به جای کاربر) که بدهی فنی را معرفی می کند و دیر یا زود در لیست تصمیمات میراث قرار می گیرد.

این امر می تواند در پروژه های بزرگ به مواقع عظیم (از چند دقیقه به ساعت) منجر شود و حتی گاهی اوقات به معرفی یک سیستم انتزاع کاملاً جدید مهاجرت که اساساً جداول را کپی می کند ، منجر می شود و سوابق را در میزهای شبح درج می کند و بعد از وقوع مهاجرت ، جداول را به عقب و عقب می اندازد. باز هم ، این پیچیدگی اضافی بر روی هر موجودی که با یک موجود دیگر با یک کلید اصلی کامپوزیت ارتباط دارد ، مجبور می شود و ساختار پایگاه داده شما بزرگتر می شود. مشکل بدتر و بدتر می شود ، بدون اینکه راهی برای حل آن در نهایت انجام شود (به جز با از بین بردن کلید اصلی کامپوزیت به طور کامل).

کارایی

اگر شما یک مدیر پایگاه داده یا مهندس داده/دانشمندان هستید ، معمولاً مستقیماً روی پایگاه داده کار می کنید و داده ها را همانطور که به آنها نیاز دارید کشف می کنید. داشتن کلیدهای اصلی کامپوزیت به هر کاربر نیاز دارد که SQL را مستقیماً می نویسد تا از همه جداول مربوط به کلید اصلی صحیح (و ترتیب ستون برای به دست آوردن بهینه سازی صحیح شاخص) آگاهی داشته باشد. این سربار اضافی نه تنها برای کسی که داده ها را بررسی می کند ، گزارش ها و غیره را سخت تر می کند ، بلکه می تواند منجر به اشکالات موجود در SQL قدیمی تر شود که یک کلید اصلی کامپوزیت به طور ناگهانی تغییر کند. SQL قدیمی احتمالاً هنوز هم معتبر است و بسیار خوب است ، اما ناگهان نتایج اشتباه به دست می آورد زیرا زمینه جدید در کلید اصلی کامپوزیت در پیوستن وجود ندارد. برگزاری یک کنوانسیون مانند ستون "ID" به عنوان اصلی بسیار ساده تر است. این امر امکان کشف آسان تر داده ها را فراهم می کند و تضمین می کند که نمایش داده های قدیمی SQL هنوز هم به درستی کار می کنند ، حتی اگر تصمیم دارید نحوه شناسایی یک شیء کاربر را به طور منحصر به فرد تغییر دهید.

تغییر شکل

هنگامی که از یک کلید اصلی کامپوزیت در یک نهاد استفاده می شود ، تغییر مجدد کلید آن می تواند به مقدار قابل توجهی از اصلاح مجدد اضافی منجر شود. از آنجا که یک موجود با یک کلید اصلی کامپوزیت معمولاً هیچ زمینه ای منحصر به فرد ندارد ، همه فیلتر و پیوستن به تمام مقادیر کلیدی کامپوزیت نیاز دارند. این بدان معناست که معمولاً کد به دانش کلید اصلی کامپوزیت متکی است به گونه ای که همه زمینه ها باید حاشیه نویسی و بازیابی شوند (برای مثال برای URL هایی مانند/کاربر/: key1/: key2). به محض تغییر این کلید ، نیاز به بازپرداخت همه مکانهایی دارد که این دانش به صراحت مانند URL ها ، نمایش داده های SQL سفارشی و مکان های دیگر مورد استفاده قرار می گیرد.

در حالی که ORM ها معمولاً بدون مشخص کردن مقادیر به صورت دستی به طور خودکار می سازند ، نمی تواند به طور خودکار اصلاح مجدد را برای سایر موارد استفاده مانند ساختارهای URL یا نمایش داده های SQL سفارشی پوشش دهد ، و به خصوص مکانهایی که حتی از ORM استفاده نمی شود ، مانند سیستم های گزارش و همهسیستم های خارجی.

پیچیدگی

با پشتیبانی از کلیدهای اولیه کامپوزیت ، پیچیدگی کد ORM با کارایی بالا مانند DeepKit ORM به شدت افزایش می یابد. نه تنها کد و تعمیر و نگهداری پیچیده تر و در نتیجه گران تر است ، بلکه موارد لبه بیشتری نیز وجود خواهد داشت که از کاربران بوجود می آیند ، که نیاز به ثابت و نگهداری دارند. پیچیدگی لایه پرس و جو ، تشخیص تغییر ، سیستم مهاجرت ، ردیابی داخلی روابط و غیره به میزان قابل توجهی افزایش می یابد. هزینه های کلی که با ساختمان و پشتیبانی از ORM با کلید اصلی کامپوزیت همراه است ، همه مواردی که در نظر گرفته می شود ، بسیار زیاد و قابل توجیه نیست ، از این رو چرا DeepKit از آن پشتیبانی نمی کند.

مزایای

گفته می شود ، کلیدهای اصلی کامپوزیت نیز مزایایی دارند ، اگرچه فقط بسیار کم عمق است. با استفاده از کمترین میزان شاخص ها برای هر جداول ، باعث می شود داده های نوشتن (درج/به روزرسانی) کارآمدتر شوند زیرا شاخص های کمتری نیاز به حفظ دارند. همچنین باعث می شود ساختار مدل کمی تمیزتر شود (با داشتن یک ستون کمتر). با این حال ، تفاوت بین داشتن یک کلید اصلی تقویت خودکار پی در پی و این روزها کاملاً ناچیز است زیرا فضای دیسک ارزان است و این عمل معمولاً فقط یک عمل فقط ضمیمه است که بسیار سریع است.

مطمئناً ممکن است چند مورد لبه (و برای چند سیستم پایگاه داده بسیار خاص) وجود داشته باشد که در ابتدا ترجیح می دهد با کلیدهای اصلی کامپوزیت کار کند. با این حال ، حتی در آن سیستم ها ممکن است به طور کلی با ارزش تر باشد (تمام هزینه های در نظر گرفته شده) استفاده از آنها و تغییر به یک استراتژی متفاوت.

جایگزین

یک سیستم جایگزین برای کلیدهای اصلی کامپوزیت استفاده از یک کلید اصلی عددی خودکار است که معمولاً "شناسه" نامیده می شود و کلید اصلی کامپوزیت را به یک شاخص منحصر به فرد چند منظوره منتقل می کند. بسته به کلید اصلی مورد استفاده (بستگی به تعداد ردیف مورد انتظار دارد) شناسه از 4 یا 8 بایت در هر رکورد استفاده می کند.

با استفاده از این استراتژی دیگر مجبور نیستید که برای همه مواردی که در بالا توضیح داده شد ، فکر کنید و راه حلی پیدا کنید و در نتیجه هزینه پروژه هایی را که بزرگتر و بزرگتر می شوند ، کاهش می دهد.

این استراتژی به معنای مشخص است که هر نهاد دارای یک قسمت "شناسه" است ، معمولاً در همان ابتدا ، و سپس این زمینه برای شناسایی هر ردیف های منحصر به فرد و در پیوندها استفاده می شود.

به عنوان جایگزین برای یک کلید اصلی کامپوزیت ، در عوض از یک شاخص چند منظوره منحصر به فرد استفاده می کنید.

DeepKit ORM از کلیدهای اولیه تقویت خودکار ، حتی برای MongoDB پشتیبانی می کند. این روش ارجح برای شناسایی سوابق در پایگاه داده شماست. با این حال ، برای MongoDB ممکن است بخواهید از ObjectID (_id: mongoid & primary = '') به عنوان کلید اصلی استفاده کنید. جایگزینی برای کلید اصلی تقویت خودکار عددی یک UUID است که به همان اندازه خوب عمل می کند (با این حال ویژگی های عملکرد کمی متفاوت دارد زیرا نمایه سازی گران تر است).

خلاصه

کلیدهای اصلی کامپوزیت اساساً بدان معنی است که پس از معرفی همه تغییرات آینده و استفاده عملی هزینه بسیار بیشتری دارند. در حالی که در ابتدا مانند یک معماری تمیز به نظر می رسد (زیرا یک ستون کمتری دارید) ، پس از توسعه این پروژه منجر به هزینه های عملی قابل توجهی می شود و هزینه ها افزایش می یابد.

با نگاهی به عدم تقارن مزایا در مقابل مضرات ، به وضوح نشان می دهد که داشتن کلیدهای اولیه کامپوزیت بیشتر اوقات فقط قابل توجیه نیست. هزینه بسیار بزرگتر از سود است. نه تنها برای شما به عنوان کاربر ، بلکه برای ما به عنوان نویسنده و نگهدارنده کد ORM. از این رو چرا DeepKit ORM از کلیدهای اصلی کامپوزیت پشتیبانی نمی کند.