Jeff Moden (1/22/2016)
I'm saying that it's no good for me and I won't have it in my shop.
Seconded.
I did a long project at a company that mandated usp_ for all stored procs. So if I was typing into object explorer to locate the procedure that runs step 1 of process 75, I would type 9 characters before a single object filtered out of the list (dbo.usp_*). Contrast, without prefixes I could just look for Process75.Step1 (if using schema for grouping) or dbo.Process75Step1 if not.
Hungarian notation was never supposed to be object/variable types (iLoopVariable, sLastName, etc). That's useless. Any halfway-competent intellisense can get that info. Hell, even the near-useless SSMS built-in intelllisense will, if I hover over an object name, tell me the object's type.
Even without that, it's only tables and views that can get mixed up, unless the developer's completely new to T-SQL.
The original intention of Hungarian notation was to designate the kind of object, not it's data type.
http://www.joelonsoftware.com/articles/Wrong.html (about 2/3 of the way down)
Oh, and as for the example for the junior dev, if I was defining the naming standard, it would be something like
PrimaryJoin_Step001_TableBackup, PrimaryJoin_Step002_BaseTableCreation, PrimaryJoin_Step003_BaseTablePopulation, PrimaryJoin_Step004_DataCalculations, ...
Now from the name I know what process it's part of (and don't need to worry about if it's part of the PrimaryJoin process or the ProcessJournal process), what step in the process and a high-level summary of what it does.
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