Коли використовувати базу даних nosql, наприклад mongodb над mysql?

Я новачок у концепції nosql баз даних і ніколи її не використовував. Виходячи з того, що я прочитав, і мало що я зрозумів, я все ще не бачу, як вони можуть бути особливо корисними, якщо ви не можете робити посилання між даними, якщо немає поняття іноземного ключа.

Як я можу зробити приклад запиту на щось просте, як "знайти всі коментарі, опубліковані цим користувачем", "знайти всі фотографії, що належать об'єкту альбому" тощо.

Чи віддаляються системи nosql від статичної реляційної моделі даних, але все ж дозволяють вам відслідковувати такі посилання, чи є щось аналогічне іноземним ключам, які ви можете використовувати в запитах?

Загальне використання

• Якщо у вас є структури даних, які чітко не визначені в момент створення системи. Наприклад, я схильний зберігати налаштування користувачів у nosql. Іншим прикладом була система, де користувачам потрібно було додати поля під час виконання - дуже болісно в RDBMS і вітер в NoSQL.

• Якщо ваша модельна структура в основному зосереджена навколо одного або кількох модельних об'єктів і більшість відносин є фактично дочірніми об'єктами основних об'єктів моделі. У цьому випадку ви виявите, що у вас буде досить мало потреби в фактичних приєднаннях. Я виявив, що система управління контактами може бути досить непогано реалізована, наприклад, у nosql. У людини може бути декілька адрес, телефонів та електронних листів. Замість того, щоб складати їх кожну окрему таблицю, всі вони стають частиною однієї моделі, і ви маєте один предмет.

• Якщо ви хочете скористатися кластеризацією даних на декількох серверах, а не мати один монолітний сервер, який зазвичай вимагає RDBMS.

• Кешування. Навіть якщо ви хочете дотримуватися RDBMS як основної бази даних, може бути корисним використання бази даних NoSQL для кешування результатів запитів або збереження даних, таких як лічильники.

• Зберігання документів. Якщо ви хочете зберігати цілісні документи, у базі даних деякі бази даних NoSQL (наприклад, MongoDB) фактично спеціалізуються на їх зберіганні.

А як щодо приєднання?

Чесно кажучи, жодна річ не приєдналася до мене також на початку. Але фокус у тому, щоб припинити думати в SQL. Ви дійсно повинні думати з об'єктом, який у вас є в пам'яті, коли ви запускаєте свою програму. Вони повинні бути більш-менш просто збережені в базі даних NoSQL в міру їх розміщення.

Оскільки ви можете зберігати свій повний графік об'єктів із дочірніми об'єктами, більшість потреб у приєднанні виключається. І якщо ви знайдете потрібну, вам доведеться кусати кулю і витягнути обидва об'єкти та приєднатись до коду програми.

На щастя, більшість драйверів можуть приєднатися до вас, якщо правильно встановити схему.

Для подальшого читання я фактично рекомендую Мартіну Фаулеру .

Я б точно використовував таку базу даних на етапах планування проекту (до розробки, ще до проектування) для запису даних, структура, зв’язки та характеристики яких ще не відомі та підлягають аналізу. Я б спробував зробити так, щоб після цього все відповідало реляційній моделі.

У деяких випадках вам не знадобляться сторонні ключі. Наприклад:

Знайти всі коментарі, опубліковані цим користувачем

може бути таким же простим, як завантаження commentsчастини документа, що відповідає користувачеві. Це називається денормалізація : замість того, щоб мати два набори з приєднанням, у вас є один документ, і все, що вам потрібно, знаходиться всередині документа. Один запит, ніяких приєднань, краща продуктивність .

Але в деяких обставинах це може призвести до дублювання даних , тому посилання з одного документа на інший може бути придатним. У цьому випадку вас можуть зацікавити нормалізація MongoDB, зовнішній ключ та приєднання , сторінка посилань на бази даних і особливо функція DBRefs.