June 11, 2015 at 8:08 pm
Comments posted to this topic are about the item The Rename Game
June 11, 2015 at 11:51 pm
Hi,
Renaming is vital when maintaining a database as it means you can refactor it to improve the quality of it. The areas I mean are having consistent naming, fixing typos or just when things change.
This is the main reason I use ssdt, the refactoring support is something I haven't seen in any other ode i and means you can correct things without having to manually correct it, just refactor-->rename done.
Ed
June 12, 2015 at 1:08 am
there is an issue when renaming a module: the name in syscomments (create procedure .... ) is not updated.
and if you use the source from syscomments e.g. to deploy the module to a different database,
you create an object with the initial name.
This also may happen if you decrypt a source.
June 12, 2015 at 1:17 am
I almost never rename objects for older legacy systems - I mainly have tinges of regret over object names in these cases.
I am certainly more thoughtful now about how I name objects and I am better at naming them.
Of course users don't know as the objects are presented to them with correct labelling using whatever aliasing the front end allows for. 😉
My worst offences are were something needs included and for whatever reason I can't add an extra field - yet I have fields originally designed for other purposes but with the correct data types. I have been known to use them for something completely different from their intended creation.
In my defence - its very rare
cloudydatablog.net
June 12, 2015 at 1:23 am
My worst offences are where something needs included and for whatever reason I can't add an extra field - yet I have fields originally designed for other purposes but with the correct data types. I have been known to use them for something completely different from their intendted creation.
Fetch the pitchforks 😀
June 12, 2015 at 3:11 am
I really, really like my naming to be exactly how I want it, and make every effort to get that right first time. In the course of modelling someone might use a plural (we're using singular pretty much exclusively) for a table name which is then corrected straight away, that sort of thing.
Tables - only renamed after roll out if there is remodelling for some reason - then I'd never hesitate. EF makes this easy code side, SQL Search makes proc refs easy to root out.
Procs and views might be renamed if their purpose changes but then they are effectively as new.
Column and constraint renaming seems almost non-existent once the code is in use.
June 12, 2015 at 5:24 am
I don't generally rename tables, columns, etc. once they're in production. There are just too many things that reference it.
Procedures are simpler to rename, but they have to be evaluated on a case-by-case basis to see if it's worth the risk.
June 12, 2015 at 5:27 am
i DO renaming.
To find all references to the old name i use script which simply scrawls through all my sources
and looks for occurrences of the old name.
June 12, 2015 at 5:46 am
It depends on the business value and cost.
Typically I do not like to rename things once they are shipped to production even with the ease of SSDT to refactor. Primarily because of the necessity for custom deployment update scripts, and the fact that we ship software to multiple sites and they are not internal applications.
You never know what sort of data pulls for warehousing or 3rd party integration have been written over the database at a customer site, unless the product has a full suite of APIs exposed.
While they may not technically be part of your product the first support call will most likely come to you when one of these things break.
If structural changes are needed at a significant level then I use stored procedures or views to replace the old model with backward compatible contracts over any new model.
June 12, 2015 at 5:49 am
When you don't have control of the database such as in this scenario then you have a entirely different set of rules to environments where you do have control.
June 12, 2015 at 5:49 am
Ed Wagner (6/12/2015)
I don't generally rename tables, columns, etc. once they're in production. There are just too many things that reference it.Procedures are simpler to rename, but they have to be evaluated on a case-by-case basis to see if it's worth the risk.
Even the queries you have saved on your hard drive for the ad-hoc questions that come up frequently?
What about the executable someone else on your team has written?
June 12, 2015 at 5:51 am
Joel Ewald (6/12/2015)
It depends on the business value and cost.
Agreed. Risk versus reward has to evaluated.
June 12, 2015 at 6:02 am
We don't really rename stuff. In the design phase the objects are named for what they are. This helps with references and joins later as well as knowing what the table is for when you read the name of it, but it can also create some monster table names.
Regards, Irish
June 12, 2015 at 6:12 am
Renaming badly named objects in the first place, outside the standard naming convention are done to support generic support scripts when things goes bad (because it's not if it will happen but when it will). Otherwise names aren't changed.
As some said, risk versus gains
June 12, 2015 at 6:14 am
Having lint on databases as they age is normal, refactoring is risky.
My rule is: You break my interface, and I breaka u face.
Viewing 15 posts - 1 through 15 (of 55 total)
You must be logged in to reply to this topic. Login to reply