Question

So just getting started with Azure tables- haven’t played with them before so wanted to check it out.

My understanding is that I should be thinking of this as object storage, rather than a database, which is cool. But I’m a bit confused on a couple points…

First, if I have one to many object relationships, what should the partitionkey of the root object look like? For example, let’s say I have a University object, which is one to many to Student objects, and say Student objects are one to many to Classes. For a new student, should its partitionkey be ‘universityId’? Or ‘universityId + studentId’? I read in the msdn docs that the RowKey is supposed to be an id specific to the item I am adding, which also sounds like studentId.

And then would both the partitionkey and rowkey for a new University just be universityId?

I also read that Azure Tables are not for storing lists- I take it that does not refer to storing an object that contains a List…?

And anyone have any links to code samples using asp mvc 3 or 4 and razor with azure tables? This is my end goal, would be cool to see what someone who actually knows what they are doing does 🙂

Thanks!

Answer 1

You’re definitely right that Azure Tables is closer to an object store than a database. You do have some ability to query on non-key columns, and to do logic in queries. But you shouldn’t plan on using those features for anything performance critical.

Because queries are only fast if you specify at least a PartitionKey (and preferably a RowKey or range or RowKeys) that heavily influences how you lay out your tables. The decisions you make at the beginning will have big performance implications later. As a rough analogy, I like to think about them like a SQL Server table with the primary key as (PartitionKey + RowKey), that can never have another index. That’s not completely accurate, but it’ll get you thinking in the right direction.

First, if I have one to many object relationships, what should the partitionkey of the root object look like?

I would probably use the UniversityId as the PartitionKey. That’s generally a safe place to start.

For a new student, should its partitionkey be ‘universityId’? Or ‘universityId + studentId’?

How do you plan to query the students? If you’re always going to have their UniversityId & StudentId I would probably make them the PartitionKey and RowKey, respectively. If you’re mostly going to query based on StudentId, I would use that as the PartitionKey instead.

would both the partitionkey and rowkey for a new University just be universityId?

That’s a viable choice. You can also use a constant value (eg “UNIVERSITY”) for the RowKey, if you’ve really got nothing else to put there.

I also read that Azure Tables are not for storing lists- I take it that does not refer to storing an object that contains a List…?

I’m not entirely sure what that means. Clearly you can store a collection of objects in a table, that’s what they’re for. You can’t directly store a list in an entity property. So if your Student has a property of typee List, that can’t be stored directly. But you could serialize it to XML or binary, and store that.

I don’t have any code samples handy, unfortunately. This may be a good time to abstract your data logic into its own layer, rather than putting it in your MVC controllers. We’ve found that a well-abstracted data layer can make unit testing your logic very easy. If you create some interfaces for your tables, it’s very easy to create mock objects using just a List and some LINQ.