Amazon SDB Columns VS Rows in Relation to Bandwidth and Delay

Question

We're making an SDB Domain with 3 fields essentially creating a structure similar to a "Many to many" relational table. These fields are: Employe_ID, Project_ID, Position (quick example).

What are the pros/cons of using either one of the following in relation to the traffic, delay, and cost interacting with Amazon Simple DB:

1) Creating a row for each of the 3 value combinations leading to large number of rows:

• 1,1,Lead
• 1,2,Dev
• 1,3,Manager
• 1,4,Tester
• 2,1,Tester
• etc...

2) Creating 1 ROW for each employee, and utilizing some kind of delimited key-value string:

• 1, 1~Lead;2~Dev;3~Manager; 4~Tester
• 2, 1~Tester
• etc...

I'm aware of the 1024 limit, but in the specific domain we will not pass this limit. The main concern is that there will not be many Project_id~Position key/value combinations, so is there a difference between approach 1) and 2) and which one is more suitable to save synchronization time and bandwidth transfer costs.

Answer 1

Both methods are obviously going to work, but the difference in them is mostly about maintainability.

Using method 2 might allow you to save some in bandwidth (less repeating information) but I truly doubt the Amazon costs savings can offset the effort / man hours spend in implementing/extending/maintaining this structure.

Plus, if you ever expand this system, you have the real danger of actually hitting that 1024 limit, which (though improbably) is a risk you shouldn't take for marginal savings.