The answer here is dependent on what the methods themselves are doing. With a name like
loadDataFromDB() it seems that your are actually loading the object from the database. If that's the case, you should definitely be doing that elsewhere. Normally, database interactions involve transaction management, authentication of some sort, connection opening and closing, thread pool management, etc. Even if you are using an ORM, I'd still argue that separation of concerns would make a distinction between modeling domain and accessing your domain from a datastore. For one, you are potentially coupling your model to the store itself. What if you are using an in memory thread safe map for development, but want to use postgres for production? That's a bit unlikely, but believe me, datastores change often when an app must scale. Programming to a DAO interface would allow you to simplify the calling code and decouple you from the specific store.
If on the other hand, lets assume JDBC here for the sake of example, you need to turn a
ResultSet into a POJO, then a constructor in your domain's class that is of the form
public PlayerInfo(ResultSet rs), is perfectly acceptable in the domain model itself.
In either case, data access doesn't belong in the domain model itself. In your case, some sort of
DataProvider class that loads all domain models on startup makes the most sense. This class would have a single entry point thats called in your app server's start up process. This entry point would then make calls to load all data models however you needed