Inspired by the name change of the late Inigo Montoya*.
So when you get a name change all your old posts get the name change too. Does that mean your old name can be used by a new user or is it retired? I thought of it because Inigo Montoya seems to be a new that any PB fan might think of taking. Having another new one might be confusing.
*not dead just had a name change.
This isn’t a new name question. I’m pretty sure it’s been asked before.
Ok so its an old new name question.
Yes. All the posts get reverted, but your name in any of your old posts that someone has quoted obviously will still have your old name, as it doesn’t affect text.
I asked the same question some years ago about whether or not old names can be reused if they’ve been changed, and Tuba gave a curt “No.” (Actually it wasn’t quite that curt, but the point is still the same.)
Now that was some years ago, so things might have changed. If not, though, there will never be another Inigo Montoya or Mjollnir or slythe. 
vBulletin has a username reuse delay setting (in the AdminCP, it’s under vBulletin Options / User Registration Options, at the bottom) that sets the number of days that must pass before a changed username is available for reuse. I don’t remember what the default setting is, but it can be set to zero to disable username reuse. I’m guessing that’s been done here, maybe an admin can confirm?
No, we don’t recycle names. That would just lead to confusion, especially in the case of a fairly prolific poster like the one mentioned in the OP. Of course, the name changes on your posts, but it doesn’t change where you’ve been quoted or mentioned by name in a post or thread title.
Name changes are generally undesirable, not just for the obvious reasons of annoyance and confusion, since one name change can hit the databases pretty hard; not to mention leaving overhead in those databases.
What did he change it to?
There’s an active thread in MPSIMS.
Ah yes. So there is. Thanks.
From all that I think I know about databases, and depending on how a particular database is implemented, there should be nothing intensive about changing a user name. Specifically, it should NOT be necessary to search through the entire 50-bazillion records to find and update every place the name appears.
Rather, a user name should appear exactly ONCE in ONE field of ONE record of ONE table in the entire database, and all other references to the name should simply be references to that one record. (Aside from the fact that user names are often written into the text of messages, including at the top of quote boxes – which, as noted above, do NOT get updated.)
If, in fact, user names are stored this way in the vBulletin database (that is, if the database is designed in a competent and rational way), there should be no problem with it. I’m not sure what left-over “overhead” might refer to.
Interesting
However:
** The biggest reason is a bunch of “nasty” SQL queries have to run on the DB servers, and the database for the forum is just getting too big. In some cases, a username change can seize up (meaning no one can use that server for the forum) a DB server for 5-10 minutes. Forces a few full table scans on many gigabytes of data.**
** So from now on, you need a very, VERY good reason to change it (I can’t think of a good enough reason off the top of my head, but maybe there is one). **
From Digital Point forums on name changes no more.
Which is why I followed Digital Point’s lead on name changes.
Ah, maybe there’s the rub. vBull means well, or used to. Sort-of. Very old though.
Databases need to be cleaned up like engines every now and then; hosed down, scrubbed, polished etc., this is called repair and optimization.
From StackOverFlow:
In MySql what does overhead mean
Every database will, over time, require some form of maintenance to keep it at an optimal performance level. Purging deleted rows, resequencing, compressing, managing index paths, defragmenting, etc. is what is known as OPTIMIZATION in mysql and other terms in other databases. For example, IBM DB2/400 calls it REORGANIZE PHYSICAL FILE MEMBER.
If you are talking about the thing that phpMyAdmin calls overhead, then it’s actual size of a table datafile relative to the ideal size of the same datafile (as if when just restored from backup).
[Mini-lecture on relational database design]
All true. Maybe, sometimes, in some cases.
True, databases need clean-up and re-optimizing from time to time. This arises particularly after a lot of record additions and deletions have happened. This is analogous to de-fragging your hard disk, only it happens within your database file(s) on a record-by-record level. Indexes periodically need to be re-built. This would also happen after a number of records have been deleted, newly created, or their indexed fields modified. In that regard, changed user names would simply count as one such record, contributing to the need to re-index, just like new and deleted records.
If the database is properly designed, as described earlier, simply changing a user name should NOT require a full scan, but simply requires changing one field of one record in one table. If the field is indexed (as a user-name field obviously needs to be), this also requires updating the index just like adding or deleting a user name. Once a bunch of these have accumulated, a full index re-build might be a good idea, but this is going to be happening from time to time anyway. I don’t imagine user name changes to be a major contributor to this.
It shouldn’t matter if vBulletin has been around a while. Relational database theory has been around since the late 1960’s or so, and has been well-known and well-understood (by some programmers, anyway) for quite a long time.
Now, if existing user ID numbers could be changed, then you would be looking at major time-consuming full scans every time it happened. That’s why primary key fields, once assigned, are typically cast in concrete and unchangeable forever and ever and ever.
[Mini-lecture on relational database design]
ETA: I should clarify, that I am not a vBulletin guru and I know nothing about the internal design of vBulletin databases. All of the above assumes that vBulletin databases are well-designed according to relational db rules as I understand them.
There is a setting in vBulletin that asks how long an old discarded user name should be embargoed before it can be used again.
This setting can be for a long period of time, or a short one, or none at all.
I forget what setting we used originally but I think I can safely guarantee you that once a name has been used on this board unless the name is inputted manually by an administrator it will not be used again in anyone’s lifetime here.
Thing is, doesn’t really apply to vBulletin, working with which approaches more art than science.
It’s not merely that each change is logged in the userchangelog table; but, as a couple of instances:
**Actually, it turns into a major issue pretty quick. Username is indeed a field in the user table, but for speed reasons Jelsoft also stores username for each post in the post table.
This means when you change a username, a query like
"update post set username=“NewUsername” where username=“OldUsername”; gets run.
If you have a lot of posts (like my site, nearly 39 million), it will lock your database up pretty well for a couple minutes.**
http://forum.codejoomla.com/open-source/vbulletin/changing-user-names-vbulletin-20971.html
When I change a username, it has to look through and update the data in the 10 million row database. And unfortunately a lot of this time it is performing text-based replace on serialised blobs of data… a few techies who read that will go WTF!? And that’s the problem.
The issue is that vBulletin stores usernames in lots of tables. It copies the data for performance reasons. So there isn’t just 1 row of 1 user table to update, there’s 10,000 rows of the posts table if you have 10,000 posts.
**That’s still fine, but where there really is a problem is with the private message table. The “send message to” is stored as a serialised PHP object… a string that looks like JSON. And within that may be the username, and the storage engine for private messages is MYISAM to allow search to work, and MYISAM does a full table lock on UPDATE. An UPDATE that locks whilst searching through the over half a million private messages.
**
erc.
http://www.lfgss.com/thread95475.html
I’m not going to denigrate vBulletin — apart from their creative charging policies — they have served me and others well, but no-one should expect any software not to have strange ways.
In any case, even if there weren’t ill-effects, I would still oppose name changes as selfish and rude.
(Bold subtracted.)
True, fields that theoretically should appear just once can be replicated in other tables for better performance, like user names in the posts table. That’s a common trade-off to do. But in a place like a post table (as I imagine it), wouldn’t the user name field be indexed even if it’s not the primary key? That should make it fast to update. Or is that 10-minute lock the time it takes to update even so?
But searching for names in arbitrary text-fields, let alone serialised blobs thereof?
Yeah, WTF!?
vBulletin doesn’t update user names that are written into the posts people have already made. Why does it do this with private messages?