How to store device tokens in our database for push notifications?

Question

We're in the process of setting up push notifications for our app and have found out that we'll run into a couple issues if we store the users device token in the users table.

1. The user will only be able to receive push notifs on the one device (they could be logged in multiple)

Our users table:

| id (user pk) | ... other fields | device_token (for push notifs) |

The other 2 solutions would be to:

1. Store a JSON array in the users table
2. Create a second table called user_devicetokens & link the user_id & device_token + any other settings which may be helpful.

I'm wondering how others do this & whether these solutions can be improved in any way?

Answer 1

i think you should try : Store a JSON array in the users table this way is clear and best for optimize Json document be like :

{
user_id : "user id",
list_devices_token : [....];
}

Answer 2

It's not clear what database you're using, but if it's relational (like MySQL) than a JSON array would violate the first normal form of good database design. And is, in my opinion, a non-starter.

Storing a single device id on the user table is an ok solution considering you said you'd only ever send a push notification to one device. But there are two downsides to this apporach in my opinion (not to say it's wrong , but just things to consider):

• Are you sure your concerns won't change? What if you wanted to push a notification to drive the user to update their app? Surely you'd want to send them to every device they had it installed on. This won't work with one column storing just one device id.
• Or what if you decide you want to also be recording what app version they're on? This would necesitate adding at least one more column to your user table for app_version . Extend this further ( date_last_notified ? device_type ? etc) and you've suddenly added a lot of extra columns to your user table that might not relate to the user entity as clearly. This would violate the 2nd normal form of relational database design because your new user columns will no longer describe the user entity.

The extra table for device ids referring to users does add some complexity, but this is what relational databases were designed for.

My recommendation is to give it a separate table now, but if you're going build it with a column on the users table that's fine too - just be prepared (and fearless) when the time comes to refactor.