Q: Are there apps and features to do this?
Yes.
Q: Should you use them?
Probably not. The problem with SQL is that it's extraordinarily hard to catch all of the references to object names.
One example is dynamic SQL - the technique of building strings, and then executing the string as a query. My stored procedure might have code like this:
DECLARE @StringToExecute
SET @StringToExecute = 'SELECT * FROM dbo.'
SET @StringToExecute = @StringToExecute + 'MyTableName;'
EXEC (@StringToExecute);
If you want to rename dbo.MyTableName as something else, you're going to have to look at strings inside stored procedures and app code. That's really hard to do because this is also valid:
DECLARE @StringToExecute
SET @StringToExecute = 'USE Database1;'
SET @StringToExecute = @StringToExecute = 'SELECT * FROM dbo.'
SET @StringToExecute = @StringToExecute + 'MyTableName;'
EXEC (@StringToExecute);
SET @StringToExecute = 'USE Database2;'
SET @StringToExecute = @StringToExecute = 'SELECT * FROM dbo.'
SET @StringToExecute = @StringToExecute + 'MyTableName;'
That builds two different queries for two different MyTableName's in two different databases.
Another example is linked server queries. Any of your other SQL Servers may be set up with linked servers, synonyms, views, etc to query your existing objects.
So object name changes and table refactoring is really something you can only do when:
- Your app is fairly young
- You have very tight control over the queries
- You know everywhere that queries come in from