TALKING ANDROID

Summary: As a developer, look at SimpleDB as an XML document.  Use it for social apps like Facebook and mobile applications.

Amazon SimpleDB stores accessible data in the Amazon cloud.  It is not a traditional relational database.

Alan Williamson makes the case for renaming the service to Amazon Registry to better describe his view of the service. I think this is close, but not quite right.  Google calls its datastore BigTable.  If I was doing the naming for Amazon, I might call SimpleDB “BigDocument.”As a developer, the way I look at SimpleDB is as a set of arbitrarily large XML documents.  The data is hierarchical, easily changed, and does not need to match within each element. Those are all advantages!

SimpleDB implements a hierarchy of Domains, items, and attributes.
I could have a domain called Users.
Users contains items which have an item name and a list of attributes.
Attributes are a set of Name/Value pairs.

For the Users domain, I want to carry a unique id per user, the timestamp that they added the application and the last time they access the app.
That looks something like:

Domain: User
———–Items: Unique Identifier(user_id)
———–Attributes:
———————-user_id
———————-first_access
———————-last_access

When a user takes an action, I would want a different data store.  We can consider a hypothetical game of Rock/paper/scissors to be played between 2 people.
One person has a turn and
1. Chooses an opponent
2. Chooses rock, paper, scissors
The opponent is notified and chooses rock, paper, or scissors and the game winner is decided.

Thus far, when I’ve used SimpleDB, I’ve created a separate Domain for this.  Call it GameTurns.

Domain: GameTurns
———–Items: Unique Identifier (player1+player2+date_time_stamp_
———–Attributes:
———————-Player1_id
———————-Player1 selection (Rock,paper, scissors, none)
———————-Player2_id
———————-Player2 selection (Rock,paper, scissors, none)

When Player1 logs in, I would check the GameTurns Domain for game results or new challenges.
Domain queries take the form:
select output_list
from domain_name
[where expression]
[sort_instructions]
[limit limit]
http://docs.amazonwebservices.com/AmazonSimpleDB/2009-04-15/DeveloperGuide/

When I am using Facebook or another social site, I will have a unique_id that for this query I will call ‘current_user_id’.
So I could try:
select * from GameTurns where Player1_id=’current_user_id’
select * from GameTurns where Player1_id=’current_user_id’ or Player2_id=’current_user_id’

One of the limits of SimpleDB is that there are 100 Domains per account.  That does not seem like a lot.  And there is a general assumption of associating a domain with a table in a database.
But Items within a domain do NOT need to match in format or content.  So my GameDomain could contains items of type User and type GameTurn.

Domain: GameDomain
———–Items: Unique Identifier(user_id)
———–Attributes:
———————-type: (user)
———————-user_id
———————-first_access
———————-last_access
———–Items: Unique Identifier (player1+player2+date_time_stamp_
———–Attributes:
———————-type: (gameturn)
———————-Player1_id
———————-Player1 selection (Rock,paper, scissors, none)
———————-Player2_id
———————-Player2 selection (Rock,paper, scissors, none)

So in this case, rather than having 2 domains, I’ve introduced a new attribute called type for the item.  Type can either be user or gameturn.

Now my query would look like:
select * from GameDomain where type=’gameturn’ and Player1_id=’current_user_id’
select * from GameTurns where  type=’gameturn’ and ( Player1_id=’current_user_id’ or Player2_id=’current_user_id’)

I did not cover the idea that attributes can have multiple values.  That can come in handy for items like products that have user ratings.  There may be no ratings or there may be multiple.  That should be easy to envision within an XML document. AN even easier example is a book with multiple authors.  That’s a typical XML example.

In social applications like Facebook, you can get user profile info based on a user id.  SimpleDB makes a good datastore for user ids.  As with the example, most social applications are based on the concept of users interacting with each other. By  uniquely identifying a transaction based on user ids and timestamps, you can use SimpleDB as an effective lookup for user activity.  User1+User2+timestamp = Unique transaction id.

The same holds true for mobile.  In the case of Android, when SimpleDB returns XML data the adapter concept works well for handling and displaying that data.  (More on that in a separate post).

For mobile applications, SimpleDB can stand on its own.  The client is the device.  SimpleDB is the remote datastore.  There is no need for a web hosting service.