Please Stop Changing Player Names

[Rook]

Dear HQ,
I noticed in the last 10 days there were at least 8 changes in player names in the projections files. It would be great if Baseball HQ would pick a name and stick with it for the player's career. Since there are no player ID numbers, the name is the primary key for those who store the projections in a database. Changing names has no real benefit but can cause problems like duplicate player records and broken links between database tables.

I would be very grateful if HQ stopped this name altering habit so that less time was spent tediously checking for and updating these changes.

For those interested, here are the names that were recently changed:

Reggie to Reginald Abercrombie
Thomas to T.J. Bohn
Matthew to Matt Kemp
Fred to Frederick Lewis
Chris to Christopher Roberson
Skip to Jared Schumaker
Chris to Christopher Young
Ben to Benjamin Zobrist

[timg]

This is probably a stat service thing -- BBHQ just going with the feed.

[Rook]

This is probably a stat service thing -- BBHQ just going with the feed.

If that's the case then it would be great if HQ would give their stat service a call and tell them to quit changing names or if more than one service is being used, stop that and choose one for the sake of consistency. Having a primary key that can be relied on is a basic requirement for proper database management and it should be fairly easy to avoid continuously violating this rule.

[The Q]

In the end it's HQ's responsibility to QA all the data before they display it for users.

[Tom_T]

If that's the case then it would be great if HQ would give their stat service a call and tell them to quit changing names or if more than one service is being used, stop that and choose one for the sake of consistency. Having a primary key that can be relied on is a basic requirement for proper database management and it should be fairly easy to avoid continuously violating this rule.

I can't speak to the player name issue, but we do use primary keys in our tables. Every player has an ID number. You can see it at the end of the address when you bring up a player's PlayerLink page. Using a descriptive field like a name as a primary key is a database no-no.

The problem is not that we're changing the name, it's that you're using the name as the primary key. I don't mean you're doing anything wrong, though; you're just working with the data we give you. The proper procedure would be for us to include the ID in the projection file, so that you can incorporate it into your tables and lookups.

[MudHen]

The proper procedure would be for us to include the ID in the projection file, so that you can incorporate it into your tables and lookups.

Could you do this? I wish you could, it would really make all of our lives easier. We have no choice but to use the name as the PK. If you could get the ID in the file, man, that would be great.

[Rook]

Either solution: creating a unique player name and never changing it or giving us the PlayerID number would be a huge improvement over the weekly chore of changing the Matt/Matthews, Chris/Christophers.

[RobR]

Also, keep in mind that even if they're constant, player names are bad primary keys. They not guaranteed unique.

[Rook]

That's why I started this thread. I would love a simple guarantee that the names would be unique and stable. I want to avoid a repeat of last year when in addition to the massive number of name changes, I was constantly adding an S to one Alex Gonzalez and an A to one Luis Gonzalez.

Names can be a perfect primary key because when there are conflicts there are always options like using the formal or nick name, full middle name or initials, etc. HQ is ahead of the curve in many ways but in this one area, companies like Baseball Notebook and Baseball Prospectus are putting HQ to shame.

[Tom_T]

Names can be a perfect primary key because when there are conflicts there are always options like using the formal or nick name, full middle name or initials, etc.

Names are terrible primary keys. The primary key of any table should be a number which has no meaning and will never change. The recommended design is to store the last name, first name, and maybe nickname as separate fields, and let the user format the name any way he chooses.

We are actually doing everything properly except for supplying you with the ID.

[MudHen]

Also, keep in mind that even if they're constant, player names are bad primary keys. They not guaranteed unique.

I think we all know that. And we know if HQ made a simple change to include the ID (or a unique ID) to the file, then that would solve all the problems.

Can this be done? (seems like a simple request)

[Rook]

Names are terrible primary keys. The primary key of any table should be a number which has no meaning and will never change. The recommended design is to store the last name, first name, and maybe nickname as separate fields, and let the user format the name any way he chooses.

We are actually doing everything properly except for supplying you with the ID.

Names are not ideal but they don't have to be terrible primary keys. They are only terrible keys when the person who runs the database doesn't bother to distinguish them. Right now the only duplicate name for batters is Alex Gonzalez. Making one name Alex S. Gonzalez would solve that problem.

If another Alex S. Gonzalez came along he could be Alex Sanchez Gonzalez and if a fourth came he could be Alex San. Gonzalez etc, etc. Unlike the world's population, the professional baseball database is pretty small so there would not be practical problem to implementing this.

All that being said, if HQ starts to supply the player ID, then there is no issue and the person in charge can keep changing Fred to Frederick and back again 50 times a season and we would still be better off then what we have now.

[RON@HQ]

Up until this year, the Player ID numbers that we had been using were proprietary to our stat provider so we could not publish them. This winter we began converting to our own system, but the transition has not been smooth -- the changing player names are symptomatic of some of the bugs. Once we have a system that is bugless, and ours, I'll start publishing the ID numbers. Until then..... I'm sorry.

[MudHen]

Cool, thanks for the reply. I was going to suggest that if they were proprietary, that you just create your own unique numbers and use those. Sounds like you are doing that, awesome!!!

[rotonut]

Up until this year, the Player ID numbers that we had been using were proprietary to our stat provider so we could not publish them. This winter we began converting to our own system, but the transition has not been smooth -- the changing player names are symptomatic of some of the bugs. Once we have a system that is bugless, and ours, I'll start publishing the ID numbers. Until then..... I'm sorry.

Hallelujah!!! Can't wait for this. Will make life SO much easier not to have to fiddle around with names and actually concentrate on manipulating the real baseball data.