Я читал довольно много о Кассандре и искусстве денормализации и материализации при записи данных. Я думаю, что понимаю концепцию, и это, кажется, имеет смысл. Тем не менее, у меня есть некоторые проблемы с его реализацией в сценариях, где есть глубокая иерархическая структура данных.Как денормализовать глубокие иерархии?
Рассмотрим надуманный область, где
Владелец 1: * Компания
Company 1: * Команды
Команда 1: * Игроки
Игроки 1: * Оборудование
У нас есть столы для каждого из них но мы также хотели бы быстро запросить атрибуты оборудования владельцем, поэтому, похоже, нужно создать таблицу (OwnerEquipment) с идентификатором владельца и идентификатором оборудования в качестве первичного ключа с идентификатором владельца в качестве ключа раздела , Это имеет смысл, но что, если сценарии UX, которые добавляют и редактируют оборудование, не включают идентификатор владельца как часть рабочего набора?
Большинство примеров денормализации, с которыми я столкнулся в своих исследованиях, обычно представляют собой пример использования одного родительского или родительского типа с одним уровнем. Кажется довольно разумным, что клиент обновления будет иметь достаточную информацию о непосредственном родителе при обновлении дочернего элемента для записи денормализованного обратного индекса, но что, если данные, которые вы действительно хотели бы денормализовать, - это несколько «присоединяется»?
Эта проблема усугубляется в нашем примере, когда мы считаем, что Компания продается другому Владельцу. Предположим, что желаемое поведение для OwnerEquipment отражает это изменение. Как код, который пишет эту обновленную компанию в базу данных, обрабатывает обновления таблицы OwnerEquipment? Должно ли оно, зная идентификатор старого владельца, попытаться обновить все записи OwnerEquipment для этого владельца? Это похоже на очень не-Кассандру, что нужно делать, а также чревато проблемами параллелизма. Проблема усугубляется, когда вы двигаетесь по цепочке (Team to new Company, Player to new Team). В этих случаях «старый владелец» не обязательно находится в рабочем наборе и должен быть прочитан для обновления.
Есть ли какие-то лучшие способы подумать об этой проблеме?
Спасибо! Моя интерпретация вашего ответа, похоже, намекает на то, что для всех таблиц необходимо иметь owner_id, чтобы таблица оборудования могла иметь owner_id, является ли это, где это происходит? –
Не ** все ** таблица должна иметь owner_id. Просто поместите owner_id в первичный ключ, где вам это нужно для ** запроса ** – doanduyhai
Я думаю, это кажется немного легче сказать, чем сделать. Рассмотрим сценарий, который я упомянул, когда компания меняет владельцев.В таблице Company есть owner_id, и я обновляю его. Единственное другое место, которое я забочусь о владельцах, находится в моей таблице OwnerEquipment. Но для обновления этой таблицы мне нужно прочитать таблицы Team и Player, чтобы получить список оборудования для обновления. Правильно ли это звучит? Это тот момент, когда я думаю, что делаю это неправильно, потому что это в основном соединение. Я просто делаю это в обновлении вместо чтения. –