CODEWITHSUNDEEP
c#azureazure-sql-databaseazure-mobile-servicesazure-table-storage
Michael
Michael

Reputation: 747

Azure Mobile Services / Azure Table: How to handle list of "members"

I have a table in which I store "Events". Each Event has of course a lot of "Members". How should I handle them? Should I write their UserId's in one string splitted by |? But can query then all Events where the userId is member? How can I handle this best?

Upvotes: 1

Views: 122

Answers (2)

Andrea Coluccio
Andrea Coluccio

Reputation: 836

The fact that you are using Mobile Services changes everything. Sorry, I didn't note it when I read your post in first place.

The default data storage used by Mobile Services is SQL Server that allows multiple indexing for a specific table. In this case I suggest the following data schema:

  • An "Event" table with an Id column representing the unique id of the event plus other fields to store info about the event (description etc.)
  • A EventMembers table with an EventId field and a UserId field (both indexed)

Let's imagine we have an Event with Id 1 and the users with userid User1 and User2 are participating. You would have the following record in the table Event:

id: "1"
description: "event with id 1"

In the EventMembers table you would have two records:

eventid: "1"
userid: "User1"

eventid: "1"
userid: "User2"

Because both eventid and userid are indexed column, you can query the table to check what users are participating to an event and which events a specific user is participating.

Upvotes: 1

Andrea Coluccio
Andrea Coluccio

Reputation: 836

As you probably know, Azure Table Storage is not relational and doesn't allow any indexing other than the primary clustered (read partitionkey and rowkey). If you want to query a table by including a field in the filter clause, then this field MUST be the partitionkey or the partitionkey AND the rowkey. (In fact you can filter by other fields but the results in terms of performance would be catastrophic).

In your case I suggests to create two tables:

  • The Events table with the event id as key and putting the info about the event members in non indexed fields
  • The Members table with the userid as key and the eventid as non indexed field

When you add/remove a member to an event you need to write to BOTH tables. When you want to filter by member then query the Members table. When you want to filter by event id, then query the Event table.

I know, it sounds like a waste of storage space and duplication of information but that's the price to pay for scalability and performances. It would be much easier with a relational database but than you wouldn't benefit of the virtually limitless scalability offered by Azure Table Storage.

Regards,

Andrea

Upvotes: 1

Related Questions