Хранилище таблиц Azure - шаблон для родительского-дочернего (схема со ссылками) - PullRequest
Новая
       21

Хранилище таблиц Azure - шаблон для родительского-дочернего (схема со ссылками)

0 голосов
/ 10 мая 2011

Используя 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 запросам!

Ответы [ 2 ]

1 голос
/ 11 мая 2011
1 голос
/ 10 мая 2011

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

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

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

...