June 14, 2015 at 5:18 pm
I rename, all the time. SSDT and sensible PRs / unit tests / integration tests helps in a big way.
IMHO not renaming for fear of breaking things is tantamount to letting the codebase rot over time as definitions evolve and move on.
June 15, 2015 at 6:07 am
Put a view on top of changed definitions which provides original layout.
June 16, 2015 at 7:43 am
Alvin Ramard (6/12/2015)
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)
No, no, no! It should be aithnichear_duthcha.
Then civilised people will be able to see what it is, intead of just the barbaric speakers of a Bheurla Shasunnach. :laugh:
Tom
June 16, 2015 at 9:19 am
I don't like renaming unless it's really necessary (to make column names indicate what the column is, including to replace meaningless names like Col1, Col2, and to ensure that a table name reflects what a row in the table represents). Ideally names are a good fit with subject experts - for example a database describing recorded media might reasonably have tables called Album, Track, and so on and probably shouldn't call those things Disc, Song, etcetera, but that should normally be fixed at an early stage of design not in production.
But in order to make it possible for the schema to be changed utterly, so that the new tables are very different from the old, without impacting anything outside the database, I impose a rule that the only things to which apps (or end users) have access are stored procedures. That leaves only the changing of procedure names as an issue, since I can change the procedures to handle the schema so as to deliver the same functionality as before. So table and column changes are certainly an internal database matter only, and changing them isn't a big hassle. Of course this doesn't work when ad hoc queries are required, so there are areas in which that rule won't fly. When extra functionality is required it may be that changes in apps and SPs have to be coordinated, but ideally things should be organised so that an app can use the new versions of SPs without any code change until the app is required to deliver the new functionality - this is usually not very difficult if some rules about apps accessing result sensibly without making silly assumptions can be imposed. Again it's a good idea not to change any names unless it is actually necessary to do so.
Tom
June 16, 2015 at 9:33 am
Just out of curiosity, does anyone here use SYNONYMNs as part of your database refactoring? If so then what unexpected limitations or quirks did you encounter?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 16, 2015 at 10:15 am
Eric M Russell (6/16/2015)
Just out of curiosity, does anyone here use SYNONYMNs as part of your database refactoring? If so then what unexpected limitations or quirks did you encounter?
Yes, I've used them while moving tables from a database to another one. I've created synonyms which pointed to moved tables, as backward compatibility against the legacy database.
I've used them also when renaming the underlying objects, like stored procedures. In this case the new developments pointed to the new (renamed) objects and existing application pointed to the synonyms (until the mandatory change).
I've encountered some issues when using synonyms, but most of them are about intellisense capabilities/productivity tools.
Let's say, the underlying object must exist at runtime 😉
So, pay attention when you create synonyms, underlying objects are not checked.
Alessandro Alpi
CTO Engage IT Services S.r.l.
DBA | Team Leader
Microsoft MVP - Data platform
[MCP] [MCITP]
June 16, 2015 at 10:43 am
Alessandro Alpi (6/16/2015)
Eric M Russell (6/16/2015)
Just out of curiosity, does anyone here use SYNONYMNs as part of your database refactoring? If so then what unexpected limitations or quirks did you encounter?Yes, I've used them while moving tables from a database to another one. I've created synonyms which pointed to moved tables, as backward compatibility against the legacy database.
I've used them also when renaming the underlying objects, like stored procedures. In this case the new developments pointed to the new (renamed) objects and existing application pointed to the synonyms (until the mandatory change).
I've encountered some issues when using synonyms, but most of them are about intellisense capabilities/productivity tools.
Let's say, the underlying object must exist at runtime 😉
So, pay attention when you create synonyms, underlying objects are not checked.
OK, weird.
CREATE SYNONYM MySynonym FOR IDontExist;
Command(s) completed successfully.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 16, 2015 at 11:09 am
Here is a connect item, closed as "Won't fix":
http://connect.microsoft.com/SQL/feedback/ViewFeedback.aspx?FeedbackID=287100
Alessandro Alpi
CTO Engage IT Services S.r.l.
DBA | Team Leader
Microsoft MVP - Data platform
[MCP] [MCITP]
June 16, 2015 at 1:15 pm
We rename as needed, but use the Refactoring tool in SSDT to handle a lot of those details for us - changing the affected columns, procs, views, etc. Ideally we try to avoid renaming as much as possible, but sometimes a poor naming choice was made, an object name was misspelled, or the name no longer fits what we've actually done with the column. (Architecture didn't line up with usage or something like that - we're not talking changing its use completely mid-stream.)
It really was more of a case by case scenario and with the new refactor catching in SSDT projects, we're a bit more comfortable. Nothing is worse than the devs swearing that the columns are brand-new when they were actually renamed.
June 25, 2015 at 6:38 am
Dalkeith (6/12/2015)
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
I've done this too, use a variable for a purpose that doesn't match its name. But it just causes continuous confusion for future programmers. I now just bite the bullet and rename it, dealing with the fallout.
June 26, 2015 at 8:27 am
I do occasionally rename variables, temp tables and such when refactoring a stored procedure. So long as the input / output parameters and resultset columns don't change, then this type of encapsulated renaming is a much lower risk than renaming things like tables.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 11 posts - 46 through 55 (of 55 total)
You must be logged in to reply to this topic. Login to reply