Pretty much as the title says, I wanted to check if it is completely fine or if it is bad practice for me to store the users database ID in my websites redux store.

E.g. its a website which can have a store or customer user, if for example the user is logged in they could have their favourite store's data in an array property in redux and in that array could be a list of objects with:

{storeId:Guid, storeName:string, storeIndustryType:enum, etc...}

The guid for storeId would be the primary key of that user from the store database and aspNetUsers database.

I use these ID's for CRUD operations related to things they want to do like add a new favourite store, remove a favourite store etc..

CodePudding user response：

It's not ideal, but also commonly done this way. I wouldn't call it a bad practice, but the "best practice" is certainly different:

• Ideally you'd use a separate unique ID that is exposed to the outside (of the internal DB system), which will then be used to identify the user in API requests etc. Like an alias.
• The ID shouldn't allow to guess other existing IDs (by incrementing a counter for example), but you seem to have that covered with guid.

This question isn't specific to redux btw, it's more about how you identify entities in your system on the client side. You can alias them as described above, or expose the internally used IDs to the client. The latter is simpler and easier but less secure.