November 6, 2011 at 9:05 am
I would like to produce a design review to my boss, covering the rationale and risks of implementing a consistent PK/FK naming convention. I think I have the rationale down but not the risks. Bascially I propose to remove duplicates and rename existing PK/FK/UKs to something you can understand at a glance. I am very intrigue with Michael Sondergaards solution http://www.sqlservercentral.com/scripts/constraints/71340/ and will experiment.
What I am most concerned about is not knowing what risks are involved while and after I rename an FK, PK, or UK. Since I am not touching the constraints themselves, only their names, I personally do not think renaming will have any adverse impact.
Is this too simplistic thinking? Is it possible that a stored procedure would be dependent on the explicit name of an FK or PK? If so, are there suggestions for how I might find stored procedures dependent on the names?
What are the risks of renaming PK/FK/UKs, if any?
November 6, 2011 at 9:33 am
None, unless you have any index hints referencing those constraints (which would generally not be recommended anyway)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 6, 2011 at 9:27 pm
Thank you GilaMonster!
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply