Fozzie (1/25/2010)
GilaMonster (1/25/2010)All I find that prefixing stored procedures does is make it harder to locate them and navigate to them in Object Explorer
If they've all been prefixed with the same "tibble" then the order would be the same with as without. It's only if mixed tibbles are being used where you get issues.
Not quite the same. I'm dealing with a client's db where every proc is prefixed usp_ (there are several hundred). If I use the Object Explorer ability to type the start of the name to navigate to it, that's minimum 9 characters that I have to type to even begin to navigate (dbo.usp_<next letter>). If I type too slowly, then object explorer forgets the characters that went before and starts searching again from the next character.
It's definitely slightly harder, when scanning down hundreds of stored proc names to ignore the meaningless prefix and look for the useful part of the name
Now that's a clever trick I hadn't though about... but then the dev's would now also need to know which are views with triggers on.... Hmm not something easily seen at a glance of a name.
Why? The whole reason for doing that is so that you can change a table design and no stored proc or app code has to change. A select on the view returns exactly what a select of the table used to, and the instead of triggers on the view ensure that inserts, updates and deletes behave exactly as they used to.
New code then targets the tables, not the view. Consider the view as a compatibility view (like sysobjects)
If it has a table has to be split and a view placed above then the app code should be changed unless the app code uses stored procedures.
In that case, you probably wouldn't bother with the view. Change the table design and fix all the code that breaks because of that.
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