I agree with spelling things out but couldn't disagree more with prefixes. Love schema's for grouping Sales.Orders, Sales.OrderItem. For the folks that love a tName or vName let me ask on thing? Do you apply the same thing to your columns? After all these are types of objects as well. I worked on systems that contained very elaborate prefixes. There is a wbocspuCompany for web based object Company stored procedure update and yes there was an i (insert), d (delete), s (select). The vendor carried this into the column names as well. It is a huge pain in the a$$.
It's handy to be able distinguish between tables and views in code but I found it most useful to apply an _v at the end of the name. This gives me Customer table (nice, clean, simple) and related views Customer_v and Customer_vTop100 and Customer_vFormer.
Applying an action at the end of stored procedure names allows the sprocs based on a single object to be grouped together. I'll have Customer_del, Customer_get, Customer_upd, Customer_ins, (or Customer_sav for insert/update). If I use a prefix then I have all my del[ete] procedures together, etc. I guess that may be handy if I'm trying to modify all my delete procedures. But normally I'm making a change to a Customer table and want to change all of the code related to those items. Give me a moderate size database with 100 tables and each Customer object will have
I'll bet after reading this post you were able to figure out what the objects above do. After 15+ years of dealing with both prefixes or suffixes -- IMHO, suffixes and Object_Action names are the only way to go.
Remember, it's an opinion and it may be worth exactly what you paid for it.