I love having standards spelled out. Makes everyones job that much easier, because its readable and, well, standard.

Personally, I like naming indexes differently. I will put the index type at the beginning, so PK_TableName_FieldsInIndex. This way, I know at the beginning what type of index it is, then the table it is applied to, and the fields in that index. I do this because I've seen errors in the application that just spit out the name of the index, or foreign key or other constraint. The error want handled well, so if the name is readable, one can discern the problem easily. But it also helps me to see what indexes are there or not there, based on the name.

For triggers and stored procs, i name them trTrigger and spProcName. Only when I want a proc to be accessible via master do I name it sp_ProcName, and thats usually a helper proc for me the dba, and not a application specific one anyway. So sticking it into master will hide it from the customer, should they ever go alooking.

One final thing i would like to note, is that all sql code that I write, I use templates to start them, and save the files to disk every time. We use source safe, so i usually aadd them into that, to version control them. As I am testing a proc, for example, I will add in testing code below the actual proc create code, but within comments. So anytime I want to reload the proc, simply open up the script file, and execute it. It will drop the proc, then readd it. The testing code is in comments, but I keep that for reference. Oft times I will even record the time of execution and number of records retrieved, so at a later date, I can verify the integrity of the proc and its resulting data, compared to earlier trials.

Anyway, thats some more of what i do to maintain a clutter free dba life.