Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Natural keys are great when they're someone else's synthetic keys. My Discord bots make liberal use of this.

   model: DiscordMessage
     key = discord_message_id
     key = discord_user_id
     key = discord_channel_id
     key = message_type

   model: UserData
     key = discord_user_id
     key = field_name

   model: GuildFeature
     key = discord_guild_id
     key = well_known_feature_name

   model: DiscordEvent
     key = discord_event_id
     key = discord_guild_id
This is how I was always taught to use them so I'm kinda confused what the author is getting at. If the thing you're using as a key can change and that doesn't define the row then you don't have a key. If you're at a conference where everyone has a badge number then that's a great natural key when scanning people into your workshop. If you're at Disney and everyone has a magicband with ids then you can use that as a natural key all over the place when to you that's a visitor.


I think this is an excellent example of one of the pitfalls that the author is getting at.

(Disclaimer: not a Discord bot programmer.)

Suppose discord_user_id is an identifier like @Spivak#2024 that uniquely identifies the user. When Discord forces all users to change to unique ID's and eliminates the disambiguating numbers (or allows users to change them), then where does that leave you?

(For the unfamiliar: something like this happened. Not sure if those are really the "discord user id" used in bot service though, but suppose that they are for the sake of the argument.)


Discord's real user ID is a very lengthy number not visible to end-users nor used for other purposes.

https://support.discord.com/hc/en-us/articles/206346498-Wher...


Which only reenforces the point that using what is exposed as the ID is not safe as a natural key.


You're reading this wrong. The real ID (the Snowflake) is exposed in the API, and the UI if you turn dev tools on. That's the one I use. You don't use @username#1209 but 1247755691426542433.


It probably leaves you in the same place you’d be with a synthetic key of your own: unable to track users across this key change without additional Discord data.


Yes, but if you then reference that as a foreign key in some other table or system, then whatever migration you need to do will encompass those systems as well, whereas if you use a synthetic key from the start you wouldn't need to change them.


Discord user IDs are their numerical unique, unchangeable, id.

https://support.discord.com/hc/en-us/articles/206346498-Wher...


Does Discord guarantee, _absolutely guarantee_, that they will never change their ids? This might be a safe practice if they explicitly claim that, and you trust them absolutely. Not otherwise.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: