CODEWITHSUNDEEP
amazon-dynamodb
GGizmos
GGizmos

Reputation: 3775

Whats the proper way to implement a unique secondary index on a DynamoDB table that has no range key?

I'm a bit confused by how to properly set up secondary indexes in DynamoDB. the documentation states secondary indexes are for tables which have a hash and rangekey, but in my case, I have no need of the range key.

The scenario is basically like this. I have a list of mobile clients which will call into my API. those clients are identified by a 6 character unique client ID. Each client also has a unique device ID, which is basically a long GUID -- quite long and inconvenient to use as the primary key.

The question comes when a client registers itself it sends is device ID (the long GUID) in a registration request and the server generates the unique clientID (the six char unique ID) which it returns to the client for future communication. One of the checks that the server side must do is make sure the request is not a duplicate registration, i.e. that the deviceID is not already present in the table under another client ID.

In a SQL table, I would have the clientID be the primary key, and 'd just define the a unique index on the deviceID field, but it seems like I can't do that in DynamoDB, since I only have a hash key on the table, not a hash and range key. I could do a query to find out if there's a dupe deviceID somewhere but that would seem to require a table scan which I'd like to avoid.

What's the proper way to set up something like this in DynamoDB? Do I just use a dummy range key like "foo" on all my rows and use a local secondary index? Seems inefficient somehow.

Upvotes: 0

Views: 534

Answers (1)

Chen Harel
Chen Harel

Reputation: 10052

I personally don't like to use indexes.

What I recommend is to keep two tables.

DEVICES
Hash: device_id
attribute: client_id

CLIENT_DEVICES
Hash: client_id
Range: device_id

This allows you to reason about whether a client has devices, which devices, as well as ask for a device if it attached to a client.

This IMO is more readable than global/local secondary indexes.

Upvotes: 2

Related Questions