При правильном подходе и соответствующих задачах этого достаточно :)
Конечно бывают задачи, для которых Table Storage не очень подходит и бывает, что без SQL Azure не обойтись.
Timestamp это техническое поле, к нему конечно можно получить доступ, но индексируются только PartitionKey и RowKey и по ним самые быстрые запросы.
Точнее даже так — при использовании PartitionKey и RowKey запросы выполняются быстрее всего.
Это огромный шаг вперед. Мне нравится тенденция приводить сайты в стиль Metro. Становится удобнее использовать. А единая концепция позволяет быстрее разобраться что к чему тем, кто уже знаком с Metro.
К тому же тенденция к увеличению dpi для мониторов делает Metro-дизайн все привлекательней.
Проблема состояла в том, что Microsoft.WindowsAzure.StorageClient.TableServiceContext не поддерживает Contains в принципе. Поэтому приходится конструировать его через Or.
И вот та самая строгая типизация LINQ нисколько не помогает в решении. Конечно оно может быть и не оптимальным, но оно работает и решает наши задачи просто блестяще.
А я все же сторонник принципа «хорошее решение — это то, которое работает».
Если вы сможете предложить что-то лучшее — то с удовольствием посмотрю на ваше решение.
Да, но это все равно не решает проблему с «холостыми» транзакциями к очереди. Здесь это рассматривается как одна из проблем стандартного подхода из SDK.
Есть разные типы запросов, и по одним сценариям перезагрузка виртуальной машины не критична, по другим — критична. Поэтому для критичных сценариев в дополнение к предложенному решению используется также Windows Azure Queue, что позволяет гарантированно обрабатывать запросы. В одной из следующих статей я более подробно опишу такую ситуацию.
Описанный здесь механизм применяется для несколько других целей, нежели AMQP. Он разработан специально для платформы Windows Azure, хотя в ней существует механизм Queue, который как раз и служит для целей, которые обслуживает AMQP.
www.ksrf.ru/Treatments/Pages/default.aspx
Конечно бывают задачи, для которых Table Storage не очень подходит и бывает, что без SQL Azure не обойтись.
Точнее даже так — при использовании PartitionKey и RowKey запросы выполняются быстрее всего.
К тому же тенденция к увеличению dpi для мониторов делает Metro-дизайн все привлекательней.
И вот та самая строгая типизация LINQ нисколько не помогает в решении. Конечно оно может быть и не оптимальным, но оно работает и решает наши задачи просто блестяще.
А я все же сторонник принципа «хорошее решение — это то, которое работает».
Если вы сможете предложить что-то лучшее — то с удовольствием посмотрю на ваше решение.
А ещё есть супер crazy ролик — www.youtube.com/watch?v=emhkcqAms00
:)
Замечено: fb, vk, zvooq
Подозрения падают на flash.
(кликабельно)