• Thanks for covering an often overlooked subject (by developers without team leaders anyway).

    The choice of convention is, well, a matter of choice. The main objective being consistency of names.

    I do have one suggestion to add regarding naming of stored procedures:

    I like the object.method convention used by c/VB/other programmers. I try to follow this convention since the SPs also form part of an application's code. The names are a bit subjective, but I think it makes things quite clear. Here are some examples:

    Company_Add, Company_Delete, Customer_Get, Customer_GetOrders, etc. When to use CustomerOrder_Get or Customer_GetOrders is the common ambiguity encountered. Sometimes the parameter(s) passed in will determine the best name, e.g. CustomerOrder_Get @Customer, @OrderNum vs. Customer_GetOrder @Customer. If anyone has any thoughts on this conflict, I'd really like to hear them.

    This convention also groups the procedures for any given table/entity together, i.e. all Company related functions are listed together in Enterprise Manager/Access/Query Analyser.

    I'm not a huge fan of the "sp_" prefix practice, becasue it means I can't just hit "C" on the keyboard to go to procs called "Company_...". Also I don't see that the prefix adds any real value/clarity.

    Thanks again for raising the topic.