Лазурный стол хранения - шаблон для родительского ребенка (схема самореференции)

Question

Использование Windows Azure Table Storage (WATS) и попытка обновления приложения для использования Azure. Я прочитал много статей, и я не уверен в лучшем подходе к этому, то есть родительский к ребенку в самореляционной модели.

то есть одно родительское сообщение может иметь много дочерних под-сообщений. В модели БД это будет таблица саморегуляции.

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

субъекта сообщение/подчинение, как показано ниже. Я попытался определить PK и RK, как показано ниже:

public class TextCacheEntity : AzureTableEntity // custom table inherits AzureTableEntity 
{ 
    public override void GenerateKeys() 
    { 
     PartitionKey = string.Format("{0}_{1}_{2}", MessageType, AccountId.PadThis(), ParentMessageId); 
     RowKey = string.Format("{0}_{1}", DateOfMessage.Ticks.ReverseTicks(), MessageId); 
    } 
    public string MessageType { get; set; } 
    public int AccountId { get; set; } 
    public DateTime DateOfMessage { get; set; } 
    public string MessageId { get; set; } 
    public string ParentMessageId { get; set; } 
    // other properties... 
} 

Я думал о реализации так дочерние сообщения хранить parentMessagesId и родительский parentMessageId будет пустым.

Узор затем будет

1. Получить Родительские сообщения

   .Where(o => o.ParititionKey == "Parent_000000000000001_").Take(10) 
   

2. Получить дочерние сообщения. Перебрать все родительские сообщения и с использованием параллельного цикла для

   .Where(o => o.ParititionKey == "Child_000000000000001_" + parentMessageId) 
   

Но проблема в том, что это приведет к 11 запросов!

Answer 1

Смотрите этот пример Скотт Денсмор:

http://scottdensmore.typepad.com/blog/2011/04/multi-entity-schema-tables-in-windows-azure.html

Answer 2

Вы можете сделать это, используя тот же PK для обоих. Для этого есть несколько причин, но один из них - то, что вы также можете одновременно выпускать пакетные команды для родительских и дочерних компаний и добиваться типа согласованной транзакции. Кроме того, когда они используют один и тот же ПК в одной таблице, это означает, что они собираются вместе и обслуживаются из одного раздела. Вы менее склонны к продолжению токенов (но вы все равно должны их ожидать). Чтобы различать родительский и дочерний элементы, вы можете либо добавить атрибут, либо, возможно, использовать RowKey.

Единственный трюк к этому (и модели, о котором вы уже говорили), заключается в том, что если родительский и дочерний объекты не являются одним и тем же CLR-типом, у вас будут проблемы с сериализацией в WCF DataServices. Вы можете исправить это, конечно, создав тип uber-CLR, который имеет как дочерние, так и родительские свойства, или вы можете переопределить сериализацию с событием ReadingEntity и обрабатывать его самостоятельно.

Во всяком случае, используйте один и тот же ПК для детей и родителей. Затем, когда вы будете искать диапазоны PK, вы всегда будете возвращать родителей и детей сразу (вы можете различить предикат Where where, если хотите).