نظریاتی در باب دیتابیس ها

به این فکر میکنم که هر اپلیکیشنی که مینویسم برای حجم دیتای مشخصی برای مشتری مینویسم و طراحی میکنم.

حالا یک اپلیکیشن رو فرض کنید که قراره بین 200 الی 500 محصول در این ui که طراحی شده نگهداری کنه

و فرض کنید یک چیزی حدود 50 الی 100 دسته بندی و زیر دسته.

کاری که الان برنامه نویس ها انجام میدن اینه که ساختار رو میچینن و تحویل میدن.

به این فکر کنید که یک روزی شما 500 تا دیتا رو میچینید و بهینه سازی میکنید و حتی ایندکس ها و bplustree رو هم میچینید. و کار شما تموم نمیشه و وارد فاز های بعدی از معماری میشید.

حالا اگر یک اپلیکیشنی و تصور کنید که دیتابیسش قراره یک میلیون محصول رو نگهداری کنه. بیشتر متوجه منظور من میشید. پس ui هم باید قابلیت هایی داشته باشه. در جستجو در ایندکس در نگهداری رفتار مشتری. در تصمیم سریع اینکه صفحه ی اول باز میشه تبلیغ چی باشه. کدوم ویدئوی محصول پخش بشه و کدوم رفتار سایر مشتریان شبیه تر به شخصیت این بیننده ی سایت هستش. نیاز امروزش برای این فصل از گرما یا سرما چیه؟ همیشه راه حلش وب سرویس گوگل نیست. اپلیکیشن های آینده همه ی نیازهاش رو باید طراح و معمار سایت برای خودشون طراحی کنن. نقشه بکشن. برنامه ریزی کنن.

اگر رکورد های یک دیتابیس بشه یک میلیون. و بیش از 1000 دسته و زیر دسته داشته باشه. نحوه ی الگوریتم های بهینه سازی هر جدول و هر کوئری رو هم باید برنامه نویس مشخص کنه. آیا orm های کنونی چنین قابلیت هایی به برنامه نویس برای کانفیگ کردن انواع دیتابیس انجین sql و nosql میدن؟