I agree with a lot stated here. Couple of comments from my general experience:

Not sure I necessarily agree with prefixing objects

with t for table, v for view. From experience, this can lead to eye fatigue.

I like to add underscore so the intended table functionality can quickly be scanned.

t_

Though you might say tCustomer and tVendors is easily distinguishable, compare that to t_Customers, t_Vendors. I at least feel the prefix still allows quick discernment of a table object, but I found the underscore promotes less

eye fatigue with objects.

Regarding indexes:

I usually prefix cidx for clustered, idx for non-clustered in front of the index name. That way I can quickly scan an index list and see what I'm clustering on.

Regarding stored proceudres/views:

vw_

asp_

Again the underscore allows better readibility of the view/proc name.

I prefer asp as a prefix namely because procs list ahead of the system

sp_. I guess p would work as well; however, the difference between

p and sp, though trivial, is very close in sorting and placement in

alphabet. I too at one time used variations of prefixes for procedures

and discovered 3 letter prefix _ worked best and the a catches the eye

whereas the e can get lazy with a p sp combination. I settled on

asp_ as a preference because 'a' just jumps out ahead of 'p','s'.

Again these are just some personal preferences from working with large DBs

of mine.

We also generate a lot of temp and lookup tables in our environment.

We us lu for lookup with these tables.

In regards to : Use mixed case rather than underscores (in most cases) to indicate word breaks . Use "pCustomerAddressCreate" instead of "pcustomer_address_create".

Not sure I agree with that either for same reasons as listed above, but to each his

own I guess.

Of course avoid usage of company names when you working as a contractor across

several companies doing work.

Sales

SalesHistory

SalesCategories

SalesReps

SalesContacts

...ad infinitum....

WHile this may help you as a hired contractor keep your clients code straight,

this methodology drives internal contractors crazy.