Как разработать денормализацию схемы для обработки изменений данных? - PullRequest
Новая
       2

Как разработать денормализацию схемы для обработки изменений данных?

0 голосов
/ 30 марта 2019

Я разрабатываю схему для MongoDB и продолжаю сталкиваться со сценариями, в которых будущие обновления могут сделать недействительными мои кэшированные копии данных.Один пример - для пользователей, заказов и адресов. 

const UserSchema = mongoose.Schema({
    addresses: [{ street: String, city: String, state: String, zip: String }]
});

const OrderSchema = mongoose.Schema({
    address: { street: String, city: String, state: String, zip: String }
});

Это кажется стандартным подходом, поскольку MongoDB не предназначен для реляционной базы данных, чтобы денормализовать данные, где это возможно.Однако следующий сценарий смущает меня:

  1. Пользователь добавляет адрес к своему документу пользователя.
  2. Пользователь размещает заказ и выбирает адрес из своего списка адресов.
  3. Данные адреса копируются в документ заказа при сохранении заказа.
  4. Перед отправкой заказа пользователь обнаруживает, что он неправильно набрал адрес.
  5. Пользователь изменяет этот неверный адрес вих пользовательский документ.
  6. Адрес в объекте Order также необходимо изменить, в противном случае он будет отправлен на недопустимый адрес.

Это указывает на необходимость ссылкииспользование mongoose.Schema.Types.ObjectId для имитации реляционной структуры между коллекциями.(В этом случае, конечно, также будет коллекция адресов.) Однако есть и другие соображения, такие как исторический аспект денормализации.Я хочу сохранить фактический адрес, на который был отправлен заказ, даже если этот адрес позднее будет удален или изменен.С денормализацией это может показаться проще, чем реляционная парадигма.

Один из подходов, которые я рассмотрел, - создать коллекцию адресов, а затем пометить ее записи как недействительные, когда они удаляются, если на них уже есть ссылки в Ордене.И когда они будут изменены, мне нужно будет проверить коллекцию Orders, чтобы увидеть, есть ли ссылка на этот адрес.Если на него уже есть ссылка в заказе shipped , мне пришлось бы оставить его в покое (для исторических целей) и создать дополнительный документ Address с новыми изменениями.Все это звучит немного сложнее по сравнению с подходом денормализации.

Следующая часть вопроса касается запросов и отчетов.Если я хочу получить список всех пользователей, у которых когда-либо был адрес в Иллинойсе, мне нужно было бы пересмотреть как коллекцию адресов, так и заказы, чтобы выяснить это.Поскольку у них мог быть адрес в Иллинойсе, он использовался в отгруженном порядке, а затем был удален из коллекции адресов.

Как самые умные архитекторы данных MongoDB справляются с подобными ситуациями?Я опытный архитектор реляционных баз данных, но несколько сбит с толку концептуальной основой NoSQL.Спасибо!

...