Reader Comments
Today I’m including more comments from our readers. Maurice shares his thoughts on Database Naming Conventions. William shares a new topic about the Activity Monitor interface inside Management Studio. Feel free to share your thoughts on these or other topics by sending an email to btaylor@sswug.org.
Database Naming Conventions
Maurice:
What is the gain in adding a prefix to a stored proc, really? Adding usp_ to the name won’t make it work faster if you avoid “sp_” use. They are easy to sort out from management studio and even from system tables like sys.objects with the type_desc column or by using objectpropertyex() function.
But there is no gain in naming executable objects because the context of their use in TSQL leave no place to confusion. When someone puts Exec in front of a name it is implicit that he runs a stored procedure, and as far as I know, I can’t put a stored proc name in a from clause or a select list.
A function doesn’t need a prefix because it is written as an usual internal function in a select list of where clause (scalar function) or in the from clause with parenthesis and most of the time parameters (as for internal dynamic management view). In these places there is no means to put a call to a stored proc. There is no necessity to make them distinct. The question is what is the real value to introduce the difference?
For the case of indexes, naming conventions are useful, because indexes have sometime a dual nature. Index can be a primary key (prefix PK) unique key constraint (prefix UK) or non-unique index (IX). The prefix add some missing information. But in the case of stored procedure or function, you know what they are by the way they are used.
Where’s the Old Activity Monitor?
William:
Like many DBAs, I miss the old Activity Monitor interface of Management Studio 2005. It was intuitive and much easier to use. The first column contained an icon to let you know what was running, runnable, and hung or taking too long (hourglass). tI had more wait event columns in its presentation. It presented database sessions (SPIDs) in a scrollable listing that you could traverse easily and would not lose your place due to the refresh rate.
The hope for 2012 was a return to the old 2005 interface instead of the 2008 now-you-see-it-now-you-don’t Activity Monster processes tab. Yes, the good things about 2008: showing performance line graphs, including tabs for resource waits, file I/O, and Expensive Queries are nice, but the processes tab was so much better in 2005. If there is a petition to return to the “good old days of 2005”, I would gladly sign it.
Code Naming Conventions
Today I intend to finish up this topic of naming conventions with some further thoughts I have on code naming. Yesterday I presented some concepts with Data Domain Code. Today I want to turn to naming conventions for business logic and application control.
One of the things I have picked up as I continue my long, ongoing study of software development patterns is the value of naming classes according to the pattern they implement. For example, if I am using a factory to instantiate a class I am likely to name that factory class based on the kind of object it instantiates followed by the suffix “Factory”. The same technique may be used for a Controller, View, adapter, etc.
If I have a number of classes implementing a strategy pattern I like to have a base class name at the beginning of each strategy implementation followed by a description of what makes that particular instance different. This causes all the classes to be grouped together alphabetically in the source code making them easier to identify as working as a group. The description at the end of the class provides more information about how each one differs without having to open the code for inspection.
I haven’t really had any feedback on this particular topic. So, I hope my short list of ideas has given you some ideas for your personal implementations. If you would like to share some tips from your experience, drop me a note at btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Overview of SQL Injection Attacks
A SQL injection attack is one of the easiest ways to attack a website. This attack is directed at the core of a system, which is the database.
Featured White Paper(s)
THE SQL SERVER SECURITY THREAT — IT’S CLOSER THAN YOU THINK
Written by: Kevin Beaver Kevin Beaver, CISSP, is an independent information security consultant, author, expert witness an… (read more)