جمع‌بندی مباحث روابط بین داده‌ای

Summary of Relationships Between Data

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

فرض کنید در یک رابطه چند به چند بین نویسنده و کتاب باشیم. یعنی یک نویسنده بیشتر از یک کتاب نوشته باشد و هر کتاب نیز می تواند توسط چندین نویسنده، نوشته شده باشد. ما می توانیم برای شروع یک پایگاه داده جدید بسازیم:

Use bookRegistry

سپس collection جدید خودمان را نیز در آن می سازیم که نگهدارنده اطلاعات کتاب ها است:

db.books.insertOne({name: "My favorite Book", authors: [{name: "Amir", age: 24}, {name: "Nastaran", age: 30}]})

حالا با یک دستور find.pretty می توانیم نتیجه را ببینیم:

        "_id" : ObjectId("5e8882355159280df164b054"),
        "name" : "My favorite Book",
        "authors" : [
                {
                        "name" : "Amir",
                        "age" : 24
                },
                {
                        "name" : "Nastaran",
                        "age" : 30
                }
        ]
}

حالا یک collection دیگر به نام authors را تعریف می کنیم که اطلاعات نویسنده ها را در خود دارد:

db.authors.insertMany([{name: "Amir", age: 24, address: {street: "Main"}},{name: "Nastaran", age: 30, address: {street: "Far"}}])

من دو document جدید را درون این collection تعریف کرده ام که هر کدام حاوی اطلاعات یکی از نویسندگان است. باز هم می توانیم با استفاده از دستور Find.pretty آن ها را پیدا کنیم:

        "_id" : ObjectId("5e8882d85159280df164b055"),
        "name" : "Amir",
        "age" : 24,
        "address" : {
                "street" : "Main"
        }
}

        "_id" : ObjectId("5e8882d85159280df164b056"),
        "name" : "Nastaran",
        "age" : 30,
        "address" : {
                "street" : "Far"
        }
}

مشکل اینجاست که اگر اطلاعات یکی از author ها تغییر کند (مثلا سال بعد شود و سن نویسنده باید یک سال بالاتر بروید یا آدرس نویسنده تغییر کند یا هر اتفاق دیگری) باید به هر جایی که از author (نویسنده) استفاده کرده ایم برویم و داده های آن را به روز رسانی کنیم: یعنی هم authors و هم books باید ویرایش شوند؛ بدتر اینکه باید در books بگردیم تا کتاب هایی را پیدا کنیم که نویسنده شان، نویسنده مورد نظر ما است و سپس آن را ویرایش کنیم که بار بسیار سنگینی روی پایگاه داده ما است. همچنین احتمال خطای ما در این حالت بالا می رود و ممکن است کوئری سرچ ما ناقص نوشته شده و برخی از کتاب های نویسنده را از قلم بیندازد. از طرف دیگر در چنین حالتی نمی توانیم بگوییم به نویسنده اهمیتی نمی دهیم بلکه حتما باید سن او و نام او و آدرس او و دیگر اطلاعات او را به روز رسانی کنیم.

در اینجا راه حل بهتر پیاده سازی به شکل زیر است:

db.books.updateOne({}, {$set: {authors: [ObjectId("5e8882d85159280df164b055"), ObjectId("5e8882d85159280df164b056")]}}

یعنی به جای نوشتن نام و اطلاعات نویسنده به همراه کتاب، از آیدی آن دو نویسنده استفاده کرده ام.

جمع بندی بین document و reference

حالا سوال نهایی ما این است که چه زمانی باید از reference ها و چه زمانی از document های تو در تو استفاده کنیم. من نکاتی را به طور خلاصه برایتان بیان می کنم.

برای document های تو در تو (Embedded documents):

زمانی استفاده می شود که بخواهیم داده ها را به صورت منطقی گروه بندی کنیم (داده هایی که از نظر منطقی و عقلی به هم مستقیما مربوط هستند).
زمانی استفاده می شود که داده ها به هم مربوط باشند اما همپوشانی (overlap) نداشته باشند. بنابراین برای روابط یک به چند و یک به یک مناسب هستند اما معمولا برای روابط چند به چند کار نمی کنند.
Nesting (تو در تو بودن document ها) نباید زیاد باشد. درست است که تا 100 مرحله اجازه nesting داریم اما این یک محدودیت تئوری است. در عمل اگر حتی 50 مرحله nesting داشته باشید (تقریبا هیچ برنامه ای بیشتر از 5 مرحله nesting ندارد) برای مدیریت داده قطعا دچار مشکل می شوید. این مسئله برای آرایه های طولانی (با اعضای زیاد) نیز صادق است.

برای reference ها نیز باید گفت:

زمانی استفاده می شود که می خواهید داده ها را به بخش های منطقی تقسیم کنید نه اینکه به صورت یک گروه در بیاورید.
زمانی استفاده می شود که داده های مشترک زیادی داریم که همپوشانی دارند (روابط چند به چند). همچنین در شرایطی که داده های تکراری (duplicate data) داریم و قرار است آن ها را مکررا به روز رسانی کنیم.
یکی از استفاده های دیگر nesting برای مواقعی است که به محدودیت های MongoDB برمی خورید. شاید 16 مگابایت برای هر document از یک collection مقدار بسیار زیادی باشد اما تصور کنید که پایگاه داده شما بخواهد اطلاعات شهروندان یک کشور را ذخیره کند! در چنین حالتی ممکن است به محدودیت نزدیک بشوید.

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

در قسمت بعدی در مورد روش جالبی برای ادغام document ها در هنگام دریافت صحبت خواهیم کرد.