Функциональные возможности Azure Tables, PartitionKeys и RowKeys

Question

Итак, просто начинайте работу с таблиц Azure - они не играли с ними раньше, чем хотели проверить.

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

Во-первых, если у меня есть одно-много объектных отношений, как должна выглядеть структура раздела корневого объекта? Например, предположим, что у меня есть объект университета, который является одним из многих для объектов-учеников, и говорят, что объекты-ученики от одного до многих относятся к классам. Для нового студента, должен ли его partitionkey быть «universityId»? Или 'universityId + studentId'? Я прочитал в документах msdn, что RowKey должен быть идентификатором, специфичным для добавляемого мной элемента, который также звучит как studentId.

И тогда оба раздела и rowkey для нового университета просто будут университетом?

Я также читал, что Azure Tables не для хранения списков - я принимаю это, что не относится к хранению объекта, содержащего List ...?

И у кого есть какие-либо ссылки на образцы кода с использованием asp mvc 3 или 4 и бритвы с лазурными таблицами? Это моя конечная цель, было бы здорово увидеть, что кто-то, кто действительно знает, что они делают, делает :)

Спасибо!

Answer 1

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

Поскольку запросы выполняются только быстро, если вы указали хотя бы PartitionKey (и предпочтительно RowKey или диапазон или RowKeys), которые сильно влияют на то, как вы выкладываете свои таблицы. Решения, которые вы принимаете в начале, будут иметь большие последствия для производительности позже. Как грубая аналогия, мне нравится думать о них, как о таблице SQL Server с первичным ключом как (PartitionKey + RowKey), который никогда не может иметь другого индекса. Это не совсем точно, но это заставит вас думать в правильном направлении.

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

Я бы, вероятно, использовал UniversityId как PartitionKey. Это, как правило, безопасное место для начала.

Для нового ученика, должна ли его разделяющая клавиша быть «universityId»? Или 'universityId + studentId'?

Как вы планируете запрашивать у студентов? Если вы всегда будете иметь свой UniversityId & StudentId, я бы, вероятно, сделал бы их PartitionKey и RowKey, соответственно. Если вы в основном собираетесь запрашивать на основе StudentId, я бы использовал это вместо PartitionKey.

будет ли разделяющая клавиша и rowkey для нового университета просто иметь университет?

Это выгодный выбор. Вы также можете использовать постоянное значение (например, «УНИВЕРСИТЕТ») для RowKey, если у вас на самом деле нет ничего другого.

Я также читал, что Azure Tables не для хранения списков - я принимаю это, что не относится к хранению объекта, содержащего список ...?

Я не совсем уверен, что это значит. Ясно, что вы можете хранить коллекцию объектов в таблице, для чего они нужны. Вы не можете напрямую сохранить список в свойстве entity. Поэтому, если ваш ученик имеет свойство typee List, это невозможно сохранить напрямую. Но вы можете сериализовать его в XML или двоичном формате и сохранить это.

У меня нет примеров кода, к сожалению. Это может быть подходящее время, чтобы абстрагировать логику данных в своем собственном слое, а не помещать ее в ваши контроллеры MVC. Мы обнаружили, что хорошо абстрагированный слой данных может упростить модульную проверку вашей логики. Если вы создаете некоторые интерфейсы для своих таблиц, очень легко создавать макетные объекты, используя только List и некоторые LINQ.