Предпочтительный способ хранения дочернего объекта в хранилище таблиц Azure

Question

Сегодня я сделал небольшой срок хранения дочерних объектов в хранилище таблиц Azure.Что-то вроде Person.Project, где Person - это сущность таблицы, а Person - просто POCO.Единственный способ добиться этого - сериализовать проект в байт [].Это может быть то, что нужно, но есть ли другой путь?

Спасибо, Расмус

Answer 1

Лично я предпочел бы хранить Проект в другой таблице с тем же ключом раздела, который есть у его родителя, который является ключом раздела его Person. Это гарантирует, что пользователь и соответствующие проекты будут храниться в одном кластере хранения. Что касается кода, я хотел бы иметь некоторые атрибуты поверх справочных свойств, например [Reference (typeof (Person))] и [Collection (typeof (Project))], и в классе контекста данных, который я могу использовать какой-то метод расширения, он извлекает дочерние элементы по требованию.

Answer 2

Я столкнулся с подобной проблемой и реализовал универсальный API выравнивания / перекомпоновки объектов, который сведет ваши сложные сущности в плоские словари EntityProperty и сделает их доступными для записи в Table Storage в виде DynamicTableEntity.

Тот же API затем будет перекомпоновывать весь сложный объект обратно из словаря EntityProperty в DynamicTableEntity.

Посмотрите на: https://www.nuget.org/packages/ObjectFlattenerRecomposer/

Использование:

//Flatten complex object (of type ie. Order) and convert it to EntityProperty Dictionary
 Dictionary<string, EntityProperty> flattenedProperties = EntityPropertyConverter.Flatten(order);

// Create a DynamicTableEntity and set its PK and RK
DynamicTableEntity dynamicTableEntity = new DynamicTableEntity(partitionKey, rowKey);
dynamicTableEntity.Properties = flattenedProperties;

// Write the DynamicTableEntity to Azure Table Storage using client SDK

//Read the entity back from AzureTableStorage as DynamicTableEntity using the same PK and RK
DynamicTableEntity entity = [Read from Azure using the PK and RK];

//Convert the DynamicTableEntity back to original complex object.
 Order order = EntityPropertyConverter.ConvertBack<Order>(entity.Properties);

Answer 3

Хотя с точки зрения исходного вопроса вы, безусловно, можете хранить и родителя, и ребенка в одной таблице - вы видели ошибку при попытке сделать это?

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

Answer 4

Я предполагаю, что когда вы говорите, что человек - это просто POCO, вы имеете в виду, что Project - это просто POCO?

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

Если ни одна из этих вещей не беспокоит вас, то то, что вы сделали, вполне приемлемо.