Create a marketing application on Azure to match Facebook

"Building a Facebook based marketing application on Azure" and "building a Facebook based marketing application on Azure" (middle)

Select a store

When we pass the verification of the contact information, the user can choose a store that is suitable for his or her own preference. At the same time, the application will give the user a list of three stores (these three stores are within 50 miles of the user's ZIP code location, sorted from the most recent to farthest order). These three store listings want to be quickly displayed, and reduce the load on the Web role, calculate the distance in advance, not only that, but also from the distance information and store data to the Azure Table storage, some of the complex procedures are we should take into account and the prevention of the needle in advance. But on this basis we should understand that our goal is not to take for granted the scalability or predictability of the future, it will only make the marketing application of the existing time is shortened, so our goal is scalability.

I am using a common list of U.S. postal codes from the 1999 census (refer to: http://www.census.gov/geo/www/tiger/zip1999.html). This list contains the longitude and latitude coordinates for each zip code. Then, since I don't have my own store, I randomly select some zip codes from this list and then use these zip codes to generate a list of 1000 sample stores. Then, put this store list in the form of a CSV file (this file format is friendlier to Azure Azure Storage Explorer) and upload it to my first Azure table, where the "store" entity looks like this:

Listing 7

public class Store:tableserviceentity

{

Partition key is store number

Row key is empty

Public Store ()

{

This. Rowkey = "";

}

public string Name {get; set;}

public string City {get; set;}

public string State {get; set;}

public string Zip {get; set;}

}

Next, I built a second table called "Zipstore," which contains 0 to 3 lines for each ZIP code in the country. Each line is a "ZIP code-store" pair, and for each ZIP code, consider only the three nearest stores within a 50-mile radius of the ZIP code location. To build such a table, I have to traverse the ZIP code list and then use a formula based on latitude and longitude (refer to: http://zips.sourceforge.net/) to calculate the distance of each postal code location to each store, Save the last three stores in the range. If there is no store within 50 miles, I will give up the ZIP code. After 30 minutes of numerical analysis, I got a CSV file containing the "ZIP code-store" message, and I uploaded the file to Azure Table storage. The "Zipstore" entity is very simple.

Listing 8

Class Zipstore:tableserviceentity

{

Partition key is zip code

Row key is distance rank (0 is nearest)

public string Storenumber {get; set;}

}

"Partition Key" stores the ZIP code. The "Row Keys" is a close to the level of each store. Each "Partition" represents a ZIP code, and each line in "Partition" represents the proximity of a store and the location of the ZIP code.

Now we can take a look at the Store container:

Listing 9

public class Storerepository:istorerepository

{

ReadOnly azuretable<zipstore> _zipstore;

ReadOnly azuretable<store> _store;

Public Storerepository ()

{

var factory = new Azurestoragefactory ();

_zipstore = (azuretable<zipstore>) factory. Gettable><zipstore> ();

_store = (azuretable<store>) factory. Gettable><store> ();

}

Public ienumerable<store> getnearbystores (string ZipCode)

{

var stores = new list<store> ();

Store store;

var query = _zipstore.query.where (Zs => ZS. Partitionkey = = ZipCode);

foreach (Zipstore zs in query)

{

store = _store. Get (s => s.partitionkey = = Zs. Storenumber && S.rowkey = = "");

if (store!= null)

Stores. ADD (store);

}

return stores;

}

}

It is worth mentioning the "getnearbystores ()" method, which the controller uses to load the list of available stores. The first query specifies only "Partition key" (postal code), and then returns three or less three stores. Because the "row key" is a distance level, the query returns each store in the order of distance. For each store, we use the store number as "Partition Key" and get the store name, city, country and zip code from the store table.

Although for this view, there must be four queries, but they are all through the "Partition Key" and "Row key" to do, very fast. Also, you can buy storage space by storing all of the "store" entities directly into the "zipstore" table, minimizing the way to check for a single query to get better performance.