Unique ID for players

Yes, this needs to happen. Your solution is not overkill. In fact, it would need an extra character or another field to disambiguate the rare occurrence of twins with similar first names. Consider: Marcus Morris, morris-mar-890902 Markieff Morris, morris-mar-890902 Does it make sense to try to use parts of the name, birthdate, birthplace, etc. to indicate the player in question or should it simply be an arbitrary number?

Ideal would be an id shared with another site, e.g. baseball prospectus, espn or mlb.com. This would make it easier to mash data from different places together. ESPN's public api has ESPN IDs for (most) active players. Many of the rest of their IDs are scrapeable. I don't know whether mlb.com has a list. Or maybe whatever ids are used by your stats source. My second choice would be a unique number. Some players names are not standard across information sources. A recent example is Juan Gutierrez (baseball prospectus) and J.C. Gutierrez (espn). So, the advantages of an identifier based on names are sometimes absent. This seems simplest for you and doesn't make you dependent on another site. Whatever solution you implement, it would be great to have a cross-reference available. Baseball Prospectus publishes a limited one as a spreadsheet.

I understand the problem if you are trying to combine data between sites and services with different player IDs. But, short of getting a feed from one of those other sites, it would be unrealistic to try to synchronize with them. Plus, even with a feed, xmlstats aims to cover multiple sports and leagues, not just MLB and NBA. It needs an independent mechanism to generate IDs. However, I would consider adding functionality if the community at large wanted to add and maintain player IDs from other services.

I completely agree with you Erik. It'd be awesome to get a bb-databank shared key, but it's not practical. The Morris brothers bring up an interesting issue... maybe an arbitrary number would be easiest/best. -MG

I understand completely the difficulty of trying to maintain numbers used elsewhere. I try and routinely find errors. A unique player_id makes perfect sense.

I should add, though, that it is hard for me, when I am dealing with a large player universe, to tell some players from others. This is the main reason I settled on using the ESPN ids. I trust ESPN to assign unique numbers.

Looks to me like their player IDs start at 1 and increment by 1 independent to each sport. Just a simple auto increment key in their database. That's what xmlstats uses now, as well, but obviously the keys are not synchronized. The advantage of this strategy is that it is simple to setup and simple to enforce uniqueness. The downside is that it is yet another ID that has no meaning beyond this application. With a strategy devised to generate player IDs based on DOB, birthplace, name, etc., it would be possible to match players in xmlstats from other services (as long as those attributes used to make the ID were already present). The advantage is that the ID actually means something and could potentially be used (and generated) by other services. The downside is that it is more complicated to ensure uniqueness, requires ancillary program/script to encode and decode the ID.

My vote would be to keep it simple, and use a unique id, without the overhead required to map some meaning into the id (which isn't really good practice anyway, especially if the true intent is to use the id as a unique identifier). It's very difficult to try to make the id BOTH unique AND semantically meaningful. In the end, you end up compromising on both. Anyway, just my 2 cents. Good luck with the decision!

I agree with Bob: IDs should be as dumb as possible to keep the design as simple and as maintainable as possibile.

any news about this issue? The season is about to start thanks!

Hi again, i saw that you already have a player id in your database. Are you gonna pass it as well via the roster method?

any news here?

Sorry this is not resolved yet. The id you see on player pages (e.g., /nba/player/6420) is very much "use at your own risk" and is not supported or guaranteed to be static. It will go away entirely when this issue is resolved. Individual player summary and aggregate stats will be featured prominently in the API, so resolving this is near the top of the TODO list. Thanks for being patient.

There are only 2 players with the same name. Hopefully, they play in different teams. http://i.imgur.com/YBuKUyu.png

What about this issue? It was opened in 2013 and still nothing has been done. It would be a really useful improvement.

Hi Erik, I wanted to implement the NBA box score but then I saw your comment for Basketball Stats Object: "* - Only present for player statistics. In the future, the asterisk marked fields will probably move to a player object and embed the basketball_stats object instead." So I remembered this issue. Do you know when you'll have the Player Object done ? I know it's not an easy one but it would improve your database architechture and it would change the way we use your API. Best regards, Xavier

Hello Erik, Did you find a solution for the Unique ID issue ? BR, Xavier