June 12, 2015 at 6:18 am
Yes, I sometimes rename objects and columns. Our development process is Agile with Continuous Integration. Database changes checked into source control are deployed to QA every night. Refactoring type database changes, like column renames or schema changes that require data migration, are performed with custom script run during the database install.
June 12, 2015 at 6:32 am
Xavon: I never rename objects!
Chorus: What, never?
Xavon: No, never.
Chorus: What, never?
Xavon: Well... hardly ever!
But seriously, the most common reason I rename objects, is when a non-null column with an algorithm to back fill it is required. And then only if active systems will still need access to said table and will be able to write to the new column. In that case, rename the table, create a new table with the same name with the new column, and start filling back in from the old table with said new value tacked on.
June 12, 2015 at 6:42 am
But seriously, the most common reason I rename objects, is when a non-null column with an algorithm to back fill it is required. And then only if active systems will still need access to said table and will be able to write to the new column.
In other words, when the change is actively coordinated with development and everyone is on board with the need for the change and also the implementation plan.
June 12, 2015 at 6:43 am
WHAT'S IN A NAME?
Well, pretty much every thing.
A good naming convention always helps. And though many developers make every attempt to adhere to the naming conventions used at various clients so that no RENAMING is required; there are instances where every one has to go through the painful task of RENAMING objects.
It is not a straight forward task, but at the same time, not very painful if planned properly and executed efficiently, especially with the modern day tools to help.
Personally, I believe, that if it has to be done, it should be done. After all, its the name which gives the object its first meaning.
June 12, 2015 at 6:59 am
I had a situation where in older tables a column was named CNTRY_CODE due to column name length limitations at the time. When the name length restriction went away they started using Country_code. I could never remember which table used which name. I finally renamed the existing CNTRY_CODE columns and added a calculated column with the old name to equal the new one. That way anything that called on the table expecting the old name would still work. I only had a couple of issues where somebody tried to do an insert using the old column name where they had to change their code. I hope to get rid of the old references next year. It is just cleaner. I may be doing a similar thing with some tables. In that case, I expect to create some synonyms with the old names.
June 12, 2015 at 7:01 am
We almost NEVER rename objects outside of development. Sometimes it appears that baggage attached to the old name remains.
In production if I ever need to rename, I'd rather copy the object (sp, table, etc) into a new one with the new name, then delete the old.
...
-- FORTRAN manual for Xerox Computers --
June 12, 2015 at 7:09 am
Ed Elliott (6/12/2015)
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 😀
+1 😉
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 12, 2015 at 7:11 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.
I agree, once it goes to production you don't change it.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 12, 2015 at 7:28 am
I try to get names right the first time, but there are a couple of cases where renames happen. Mostly these are for databases my team didn't design but inherited.
1) if the business lingo for the underlying data structures is at odds with the table or column names to the point where the database calls it X but every business analyst or product owner calls it Y in every discussion, it can get confusing. Typically then we'd rename code objects too. It's not that hard when you have automated tests and such. Well, unless there are also SQL Reports - ugh.
2) egregiously misnamed things. We had a db where there were TaskIDs and TaskTemplateIDs, and a FK column in a table was named TaskID but is was actually storing TaskTemplateIDs and was keyed to the TaskTemplate table. So ... yeah.
I don't usually rename things if I just wish they were named a bit different. Consistency within a db is more important than adhering to a global convention. If the db is ALL_CAPS_UNDERSCORE names but I prefer MixedCaseNoUnderscore style, I would still name new objects LIKE_THIS.
Also next time I listen to two engineers debate CountryId vs. CountryID for an hour I'm gonna slap someone!
June 12, 2015 at 7:42 am
After reading all posts, I see everyone is doing what is right for their environment. Personally I would only work for a company that strives for clarity and purity in code; that means embracing lots of renaming. I like typing intuitive names instead of wasting time looking thru tree browsers to figure out abbreviated spelling or weirdly named things.
Using sp_rename caused me some quirky errors early on. And using the "right-click modify table" caused me many more problems. Eventually I wrote my own "modify table" scripter that works perfect for me. So, now it takes a few seconds to recreate a table or column with a new name instead of renaming. The scripter also regenerates all templated procs on a table so very few custom objects need fixed afterwards. In other words, once you have a robust change process, any requested modifications can be handled easily.
Isn't our true value in being able to quickly solve whatever problem we are given?
June 12, 2015 at 7:51 am
Personally I would only work for a company that strives for clarity and purity in code; that means embracing lots of renaming. I like typing intuitive names instead of wasting time looking thru tree browsers to figure out abbreviated spelling or weirdly named things.
I agree in principle with this philosophy, so long as tools and processes are implemented to support it. Without these it is a philosophy with a poor business case and a nightmare to support in production.
I guess my underlying business principle is that any system that clients are paying money for is a good one, even if it is not philosophically pure. Production support must be considered up front.
June 12, 2015 at 7:55 am
I have to admit I haven't been on the forums here for quite some time but what is all this talk of people slapping people 1 - you won't and 2 - it really isn't appropriate.
June 12, 2015 at 8:01 am
freecellwizard (6/12/2015)
...Also next time I listen to two engineers debate CountryId vs. CountryID for an hour I'm gonna slap someone!
It should be country_id. 😀
(just kidding)
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
June 12, 2015 at 8:15 am
I don't typically rename tables or views. There's been some badly named (IMO) tables, but I've just lived with them.
However, stored procedures are different. I've often taken an old SP and then created a new version of it, normally by appending something like "2" to the end of the name. I did this because business requirements dictate that the action(s) performed by the original SP were no longer valid, but I needed the old SP to be around while we worked on a new version of the SP and the changes to the software that used it. This is really a fairly familiar process I've gone through.
If there's a better way to do this, then I'd love to know.
Kindest Regards, Rod Connect with me on LinkedIn.
June 12, 2015 at 8:19 am
I don't use tools to generate DDL scripts, so writing T-SQL to do things like adding non-null columns, or dropping unnamed constraints and re-adding a named constraint, that's all situation normal for me. From what I recall, adding a non-null column can be faciliated simply by including a default constraint in the definition.
For a database I develope myself, I put a lot of thought upfront into naming conventions. Also, I abstract all user interaction using stored procedures and views, so that allows me a bit more flexibility in how I refactor the base tables. For legacy databases I end up fostering, I just don't bother.
There have been plenty of "Geeze, whatever dudes..." occasions where the BI team has requested that columns returned from views be renamed to something more appealing to them, but I don't fret over that. It's sort of like when one of the regular customers at a family restraunt, requests that the kitchen cut up their steak into tiny little cubes. So long as the view in question is only for the BI team's consumption, then I don't care a flip about it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 16 through 30 (of 55 total)
You must be logged in to reply to this topic. Login to reply