Whew! That was a load of work but I'm finally all finished and everything seems to still be working. :)
They're All the Same
Every wordpress installation has certain defaults. Beyond that, there are standard conventions that most people tend to use. This results in most sites being installed in the "/" or "/wordpress" directory with a known file structure, an admin named "admin" who has a user id of "1" in the database (which is called "wordpress"), a table prefix of "wp_", and a handful of passwords for all this that are typically about as secure as using "password".
In Come the Black Hats
In a perfect world, all this would be fine. Unfortunately, there are despicable low-life bottom-feeders who have nothing better to do than to invade other peoples' sites and destroy whatever they can. We then, are forced to spend inordinate amounts of time learning about security issues and how to bolster them up.
I've just finished my most recent round of security updates. One of the first things I did after setting up this site was to create a 2nd admin account and then delete the one named "admin". Unfortunately, a known user id can be a security risk as well. The default admin account is user id 1. By creating a 2nd account and then deleting the first, I eliminated user id 1 and created an admin account on user id 2. That's not a whole lot better. Hacker's must laugh at us when we do things like that.
I created another admin account and edited the database directly in order to assign a very different user id. Then I deleted the old admin account. Also, I created various other users and altered their user ids so as to help hide the real one. Hopefully that will be enough to patch that security hole.
Database Name & Table Prefixes
A more difficult issue was to change the database name and database table prefix. When you are starting from scratch, that's easy. If you have an existing database with information that you want to preserve, it gets a bit trickier.
First I created a 2nd database and copied the structure and data from the first one into the second one. Mainly this step was just done to ensure that the process worked as expected. I have a plug-in that backs up the database and emails it to me every night. I told it to do a manual backup, and create sql output, before I went any further just in case. Then I did a search and replace for every occurrence of "wp_" (the old prefix) to the new prefix I wanted to use.
Then I used phpMyAdmin to drop all the tables in the database, and then run the modified sql backup. This recreated the database with new table prefixes and modified reference to these new prefixes.
I went to look at the website and got a surprise. WordPress was trying to do a fresh install, asking me what name I wanted to use, etc. It was looking for tables that had the prefix defined in the config file and since there weren't any tables with that prefix, it assumed that this was a fresh install.
I quickly edited the config file and uploaded it. I went back to look at the site and all was fine.
One last step though. Now I had new table prefixes but I was still in the old database. Back to phpMyAdmin. I dropped all the tables in the new database to clear it out and then copied the structure and data from the old database. One more edit of the config file to point it at the new database and it was all finished.
Once Was Not Enough
I have another site set up that had the same problem so I got to run through this process twice. That's an awfully long time to work at the computer, thinking that at any moment you're gonna screw something up and spend an extra few hours just trying to recover everything. I was very fortunate and things went particularly smoothly for me.
One other step I took was to create new database users, one for each database, that each only had privileges on the database they were assigned to. Both have cryptic names with strong passwords and no unnecessary rights.
Before I could call it a day, I had to run through everything on both sites to ensure nothing was lost or disabled in the process.
I'd Rather Go To the Movies
Hours later and now both sites look exactly as they did before. Functionally, I accomplished absolutely nothing at all. Technically, the databases are safer and more secure but if there weren't hackers out there, I could have been spending that time doing something much more enjoyable or productive.