MongoDB - нереляционные недостатки - PullRequest
0 голосов
/ 23 января 2019

В настоящее время я работаю над проектом в надежде изучить MongoDB.

Справочные поля, такие как $ref, $id и $db, могут ссылаться на другие документы и коллекции и динамически искать изменения.

{  
   "_id":ObjectId("53402597d852426020000002"),
   "address": {
   "$ref": "address_home",
   "$id": ObjectId("534009e4d852427820000002"),
   "$db": "school" 
    },
   "contact": "987654321",
   "dob": "01-01-1991",
   "name": "Tom Hanks" 
}

В этом сценарии этот конкретный документ имеет ссылку на документ в коллекции ''address_home'' с идентификатором объекта 534009e4d852427820000002.

Являются ли эти ссылки менее эффективными, чем PK /FK в популярных RDBM, таких как PostgreSQL или MySQL, и почему?

Ответы [ 2 ]

0 голосов
/ 23 января 2019

Обратите внимание на это сравнение mongodb против mysql . Базы данных на основе документов более удобны для пользователя, чем реляционные таблицы кодов, и могут объединять в схеме документа логику многих таблиц, сохраняя множество реляционных структур и их обработку, множественный доступ и человеческое стремление в программировании. В хранилищах документов можно сохранять документы, код, изображения (миниатюры и фаш) и другие творческие данные, что освобождает команду программистов от криптографических диаграмм до творческих решений. Конечно, лучшие друзья хранилищ документов - это JSON, Javascipt's Nodejs и javascript во внешнем интерфейсе.

Добро пожаловать в транзакционный MongoDB4 , поддерживаемый Представлениями , триггерами , разыменования , который имеет преимущество, которое можно удаленно разыменовывать, предоставляя иерархическую структурировать базу данных с гибкими и масштабируемыми топологиями и с реактивным поведением , слушая потоки изменений . Архитектура баз данных должна настраивать детализацию и распределение данных по сетям микросервисов, избегая создания постоянно растущих монолитов. Event Sourcing улучшает согласованность и устойчивость.

Поведение FK - это строго типизированный механизм, встроенный в реляционную базу данных, базы данных документов могут быть настроены для обеспечения целостности, согласованности и задержки в зависимости от требований с помощью различных механизмов, таких как DBref, поведение транзакций, потоки изменений, функциональные триггеры, консолидация представлений. Реактивное поведение, Event Sourcing et al. в модульной композиции, которая координируется с модульностью Javascript и Nodejs, чтобы лучше соответствовать модели контейнеризации микросервисов.

0 голосов
/ 23 января 2019

DBRef - это прославленное поле id (которое может указывать на разные коллекции / базы данных для разных записей). Если все ваши адреса находятся в одной и той же известной коллекции, то это не лучше, чем просто иметь "address_id": ObjectId("534009e4d852427820000002")

Он не дает вам никаких гарантий целостности, автоматически выбирает ссылочный документ или «динамически ищет изменения» (что бы вы ни подразумевали под этим). То же самое, что и в голом поле id в реляционных базах данных (без ограничений FK).

...