I have an entity table, for example, “stories”. It will contain a large list of "stories" that people can vote on.
The main feature of my application will be users who read the “best” stories, in which there are most votes (and, possibly, other algorithms will eventually be executed).
My first thought on the structure of the Azure table:
- RowKey = unique id
- PartitionKey = ??? (possibly User Id because you can view a list of user stories)
- Title
- Description
- User ID
- Url
How can I effectively interrogate stories that are considered “best” stories? Most of the traffic will request top stories, and otherwise you do not need to highlight story ranges. What I want is a way to index top stories, but indexes are not a feature of table storage. I was thinking about saving the second table, but it can get hairy if the user updates the story in another table.
This is my first freeze using Azure Table Storage, the rest of the application will work just fine. I would not want to upgrade to using full Azure SQL because of this problem.
PS - I am open to store "top stories" in a place other than the Azure table, if that makes sense. My server will work with the C # web api, but it probably doesn't matter.