خلاصه کتاب Designing Data-Intensive Applications

فصل ۲- Data Models and Query Language- قسمت۲

Are Document Databases Repeating History?

خلاصهٔ ایده اصلی

کتاب می‌گوید:
آن‌چیزی که امروز در Document Databaseها می‌بینیم، قبلاً در دهه ۶۰–۸۰ هم در سیستم‌های قدیمی اتفاق افتاده بود.

یعنی Document DBها چیز کاملاً جدیدی نیستند؛
بلکه نسخه مدرن مدل‌های hierarchical و network databases قدیمی هستند.

📌 داستان تاریخی کوتاه

🔹 دهه ۶۰–۷۰:

قبل از SQL، دیتابیس‌ها دو مدل اصلی داشتند:

1) Hierarchical Model

داده‌ها در قالب درخت ذخیره می‌شدند
→ دقیقاً مثل Document DB

مثال:

Company
 ├── Departments
 │     ├── Employees
 │     ├── Projects

هر داده فقط یک parent داشت.

2) Network Model

دارای لینک‌های پیچیده بین رکوردها بود (شبیه گراف)

ولی کار با آن وحشتناک سخت بود:

• باید مسیر traversal را خودت بنویسی

• اگر ساختار عوض می‌شد، کل برنامه می‌ریخت

🔹 چرا SQL انقلاب شد؟

SQL آمد و گفت:

«شما فقط بگو چه داده‌ای می‌خواهی،
من خودم چطور پیدا کردنش را انجام می‌دهم.»

یعنی زبان declarative
+
ساختار زیرین abstract شد
+
join آسان شد

در نتیجه:

• maintenance بهتر

• توسعه سریع‌تر

• کد کمتر

• query قوی‌تر

به همین دلیل relational model سلطه پیدا کرد.

⭐ پیام کتاب: Document DBها در حال تکرار آن تاریخ هستند

Document databaseها (مثل MongoDB):

• مدلشان درختی (hierarchical) است

• join ندارند (یا ضعیف)

• هر document یک “parent document” دارد → شبیه همان مدل ۶۰ سال پیش

• وقتی data interconnected شود، مجبور می‌شوی reference و join دستی بسازی

• و دوباره همان مشکلات مدل‌های قدیمی بر می‌گردد

کتاب می‌گوید:
possibility دارد دوباره به همان مشکلات تاریخی برسیم.

🔥 مثال مهم که کتاب اشاره می‌کند

مثالی که از رزومه لینکدین (Bill Gates profile) زد، دقیقاً همین را نشان می‌دهد:

در JSON:

{
  "user": { ... },
  "positions": [...],
  "education": [...],
  "contact_info": {...}
}

تا اینجا همه‌چیز خوب است چون ساختار درختی است.

اما وقتی این نیازها اضافه می‌شوند:

• school خودش یک entity است

• organization خودش یک entity است

• recommendation بین دو user ایجاد می‌شود (many-to-many)

• این entityها باید share شوند

• data به هم لینک می‌شود

• join لازم می‌شود

نتیجه؟

→ درختی بودن مدل document فرو می‌ریزد
→ دوباره به همان دردسر مدل network / hierarchical برمی‌گردیم
→ باید خودت join بنویسی
→ پیچیدگی explode می‌شود

این همان historical repeat است.

🎯 کاربرد عملی این بخش برای یک برنامه‌نویس

یک برنامه نویس باید یاد بگیرد کجا Document DB انتخاب کند و کجا نه.

📌 Document DB عالی است زمانی که:

• داده ساختار درختی دارد

• تغییرات schema زیاد است

• نیاز به read تک-document سریع داریم

• داده روابط پیچیده ندارد

مثال:

• فروشگاه → سفارش → آیتم‌های سفارش

• Blog → پست → کامنت‌ها

• Event → ticket → attendees

• جریان فعالیت‌ها (activity feed)

📌 Document DB بد است زمانی که:

• داده روابط زیاد و پیچیده دارد

• many-to-many زیاد داریم

• joinهای متعدد لازم است

• داده shared بین entityهای مختلف است

مثال:

• شبکه اجتماعی مثل لینکدین

• سیستم حقوقی / ارتباطات قضایی

• ERP / حسابداری

• سیستم دانشگاهی (درس، استاد، واحد، ترم…)

• CRM پیچیده

• سیستم بیمه (که خودت هم توش کار می‌کنی)

در این سیستم‌ها:
→ SQL بهتر است
→ یا حتی Graph DB (مثل Neo4j)

⭐ جمع‌بندی

1. Document DBها در اصل نسخه مدرن مدل‌های قدیمی hierarchical هستند.

2. این مدل‌ها در داده‌هایی که روابط زیاد دارند، سریع می‌ترکند.

3. join نداشتن باعث پیچیدگی کد و duplication می‌شود.

4. SQL اختراع شد تا همین مشکلات را حل کند و هنوز هم بهترین ابزار برای relational data است.

5. یک برنامه‌نویس باید انتخاب کند:

   • tree-like → Document DB

   • graph/relationship-heavy → Relational DB