چطور ساختار پایگاه داده‌ی خود را در MongoDB تعیین کنیم؟

?How to Structure Our Database in MongoDB

MongoDB: چطور ساختار پایگاه داده ی خود را تعیین کنیم؟ (قسمت 15)

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

معمولاً در هنگام تعریف یک پایگاه داده با 4 سوال اصلی روبرو هستیم. سوال اول این است که برنامه من به چه داده هایی نیاز دارد یا چه داده هایی را تولید خواهد کرد؟ منظور من از برنامه یا application هر برنامه ای است که شما آن را می سازید (به طور مثال یک وب سایت یا یک برنامه اندرویدی یا یک دستگاه شمارش قدم و ثبت کالری که با دویدن شما مختصات GPS را به سرور خود می فرستد). این سوال به شما می گوید که به چه فیلد هایی نیاز دارید. البته در همین قسمت تا حدی با روابط بین داده ها آشنا می شویم؛ مثلا یک کاربر می تواند محصولات ما را سفارش دهد بنابراین فیلدی به نام کاربر یا user و فیلد دیگری به نام محصولات یا products می خواهیم.

سوال بعدی این است که داده ها در چه قسمتی از برنامه مورد استفاده قرار می گیرند؟ به طور مثال آیا من داده ها را در صفحه اول وب سایت خود می خواهم (همزمان با بارگذاری صفحه، مقداری را محاسبه کنیم) یا در صفحه ثبت سفارش (محاسبه قیمت و اعمال تخفیف ها) یا در پنل کاربری و الی آخر؟ پاسخ این سوال، به شما کمک می کند تا collection های خود را تعریف کنید. به طور مثال اگر یک وب سایت فروشگاهی داشته باشیم باید collection ای به نام orders تعریف کنیم تا مسئول ذخیره سازی سفارشات باشد. همچنین در همین مرحله است که در مورد گروه بندی داده ها (grouping) فکر خواهیم کرد. به طور مثال داده های مربوط به محصولات الکترونیکی را در یک گروه قرار دهیم (حالا منظور از این گروه چه یک شیء باشد چه document های تودرتو و چه آرایه ها). انتخاب گروه بندی صحیح به شما کمک می کند که وب سایت خود را سریع تر و بهینه تر بسازید. مثلاً اگر نام محصولات را به همراه قیمتشان در یک شیء یا document ذخیره کرده باشید اما توضیحاتِ محصول را در یک شی دیگر ذخیره کرده باشید، برای دریافت آن ها و نمایش آن ها در یک صفحه واحد دچار مشکل می شوید (باید با دستورات join و امثال آن، دو کوئری مختلف را به هم وصل کنید) اما اگر تمام داده های مربوط به یک محصول، درون یک شی باشد دیگر مشکلی نخواهیم داشت.

سوال سوم این است که چه داده هایی قرار است به کاربر نمایش داده شود؟ پاسخ این سوال به شما کمک می کند تا کوئری های خود را مشخص کنید. اگر قبلاً با پایگاه های داده کار کرده باشید می دانید که کوئری یعنی درخواستی برای پایگاه داده که به سرور ارسال می شود (درخواست برای همان عملیات های CRUD که قبلا دیدیم). به طور مثال آیا در فلان صفحه به یک محصول نیاز داریم (دستور findOne) یا باید لیستی از محصولات را نمایش بدهیم (دستور find)؟ آیا من به دنبال id یک محصول هستم یا می خواهم تمام محصولات را یکجا دریافت کنم؟ پاسخ به این سوالات، ساختاری کلی از پایگاه داده شما را می سازد و کلیتی به ذهن شما می دهد.

سوال چهارم این است که هر چند وقت یکبار به این داده ها نیاز دارم؟ آیا آن ها را مکرراً دریافت خواهم کرد یا هر از گاهی به سرور کوئری میزنم؟ آیا در هر بار refresh و بارگذاری صفحه به داده ها نیاز دارم یا باید در هر ثانیه آن ها را بررسی کنم؟ اگر قرار است داده های خود را مرتباً دریافت یا fetch کنید، باید پایگاه داده خود را برای خواندن داده ها (read) بهینه سازی کنید. مثلاً در چنین حالتی عیب ندارد که در پایگاه داده، داده های تکراری داشته باشیم. چرا؟ به دلیل اینکه برخی اوقات نیاز داریم که از چندین collection مختلف داده ها را دریافت کنیم (همیشه نمی توان تمام داده ها را در یک collection قرار داد) و برای دریافت چنین داده هایی باید از دستورات join استفاده کرد تا دو یا چند کوئری را در هم ادغام کنیم. این کار باعث کاهش سرعت کوئری های می شود بنابراین بهتر است همان داده ها را در چندین collection داشته باشیم (با اینکه تکراری می شوند) تا عملیات دریافت و خواندن داده ها سریع تر انجام شود.

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

تصویر زیر تمام این مسائل را به صورت خلاصه نمایش می دهد:

خلاصه ی سوالات اصلی درباره ی سامان دهی پایگاه داده — خلاصه سوالات اصلی درباره سامان دهی پایگاه داده

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