Yes, this is a properly by-the-book normalized database design. It allows operations like checking the quantity of a specific item with a single database query returning just that one number and it allows analytic queries like getting statistics about how much of what item is in the game.
If you make use of those abilities, then that's fine.
However, in many multiplayer online games, there are only two database operations which ever happen on characters. And those are:
- Save the character completely
- Load the character completely
If that's your usage pattern, then database normalization into lots of rows in lots of tables gives you no benefit, but is a lot of work and a lot of additional performance cost. You can just as well serialize the whole data of the player to a BLOB and store that in a single field of a single table row.
If you still want analytics, then you can have a properly normalized copy of the player data in a separate data-warehouse database.