I like to look at it from a separate view and usually ask myself, would I test these methods differently than the others?
If my answer is yes, I break them out into a container class because then the tests at least for that class would all be similar, same with the object.
Keep in mind a container class is useful from a testing/mocking standpoint (and dependency injection), so you can swap out the logic for getting players from a different data source without having to modify your Player object. So to have that ability, you would need to make sure your Player object has no dependency to a database, it doesn't interact with one in any way, shape or form. The container class would handle all interactions, so if you switch from SQL Server to No SQL or MongoDB, or Oracle, you just have to create a new container class.