Azure table storage has several types

Question

What do you recommend in the following scenario:

I have an azure table called "Users", where as columns:

• PrimaryKey
• Rowkey
• Mark
• Firstname
• Lastname
• Email
• Telephone

Then for each user there are different types of tasks that let you call them TaskType1 and TaskType2.

Both types of tasks have common columns, but then also have column types of type:

• PrimaryKey (this is the same as PrimaryKey for finding all tasks belonging to one user)
• Rowkey
• Mark
• Name
• DueDate
• Description
• Priority

then TaskType1 has additional columns:

• EstimationCompletionDate
• Isfeasible

and TaskType2 has its own column:

• EstimatedCosts

I know that I can store both types in the same table, and my question is:

If I use different tables for TaskType1 and TaskType2, what will be the impact on transaction costs? I guess that if I have 2 tables for each type of task, and then I will output a query like: get me all tasks where the task Primarykey is equal to a specific user from Users table PrimaryKey , then I will have to run 2 queries for each type (because users can have both types of tasks), which means more transactions ... instead, if both tasks are in the same table, then this will look like 1 query (to the limit of 1000 after pagination sessions), because I get all the rows in which PartitionKey is a user of PartitionKey, so the section is not split, h does that mean 1 deal?

I correctly understood that I will have more transactions if I save tasks in different tables ..?

Answer 1

Your understanding is absolutely correct. If the tasks are divided into 2 separate tables, this will mean two separate queries, thus 2 transactions (let now no more than 1000 entities from the equation). Although transaction costs are one reason to keep them in the same table, there are other reasons:

• By storing them in a single table, you take full advantage of the carefree nature of Azure table storage.
• 2 tables mean 2 network calls. Although the service is very accessible, you will need to take into account the scenario when the call to the first table is successful, but the call to the second table will fail. How will your application behave in this scenario? Do you also drop the result from the 1st table? By storing them in only one table, you get rid of this scenario.
• Suppose you have a script in an application where a user can subscribe to tasks 1 and 2 at the same time. If you save them in one table, you can use Entity Group Transaction as both entities (one for task 1 and the other for task 2) will be have the same PartitionKey (i.e. user id). if you save them in separate tables, you will not be able to use the transactions of groups of objects.

One suggestion I would give is to have the "TaskType" attribute in your "Tasks" table. This way you will have an easier way to filter by task.