In most learning scenarios it is helpful to understand and define the data you are working with before anything else. To get to this step, we’ll lay out a few features of the mini-product we’ll build.
Now, in order to accomplish this, there is really not that much that needs to be stored. You would probably need a username and password (you could easily just store a user ID, though, and foreign-key it into the ASP.NET membership services, but it’s easier just to store a username and password). You’d also need a list of stock ticker symbols that the user wishes to track. You need to have a setting to opt-out of push notifications; not only is this a good design principle but it’s also required for the Windows Phone app to pass certification testing. And you’d need a primary key.
Each one of these rows in this table represents a user and their preferences. Simple data model, simple app, easy to learn. So, here are our fields:
What the heck did I just show you?
This is from the fancy new SQL Azure management interface at windows.azure.com, based off of Project Houston, a Silverlight app built that allows you to create and modify database schemas for SQL Azure. Why not just do this in SSMS? Well, SQL Azure is architected a little differently than SQL Server to allow for high availability, concurrency, and the ability to run in the datacenter in the Windows Azure fabric.
I’ll preface this by saying you don’t have to use SQL Azure to get this to work. This is just a great opportunity to learn how to use it. If you choose to use your own hosted SQL Server somewhere, you can just create LINQ to SQL bindings to that server when we get to that step.
Your SQL Azure table is ready to rock. In the next post we’ll expose a couple of services to allow a phone to register to receive push notifications.