Stored Procedures

[jeffmadison]

Personally, I love the ObjectVerbModifiers naming convention. The sorting obviously makes it much easier to find stuff and to prevent creating redudant sprocs. It also seems to lead to more predictable names so that people don't even have to look up the list. I suspect that's because the VerbObject style is more like English, which is more loose and unpredictable.

I've used this convention on a few recent projects and found it to be a joy, both from a DB engineer perspective and that of a middle tier developer.

However, the main downside is that web services more often use the VerbObject convention. Can you have your web service interface use one convention and your sprocs another? Of course. But if you're using a data access layer (DAL) that provides more automated support when your operations and sprocs are using the same convention, you'd have to decide if the convention is worth it. Better yet, you could just modify your DAL to automate things either way.

[Arnie]

I highly recommend a object naming convention of [Object][Action][Modifier]. I go one step further and recommend staying with the CRUD Actions -instead of SELECT, GET, FIND, etc., use READ. (Some sprocs may have non-CRUD actions such as CALCULATE.) A large DEV team on a large project can be very creative in naming. I want to be able to minimize duplication of effort, and ease of locating (and reusing) similar existing code should be the primary focus of how names are created.

Also, what value is added by a [PREFIX]. A lot of folks use sp, usp, etc. (hopefully, not many use [sp_]), and what is the added value? You know that it's a sproc by context. You are needlessly wasting keystrokes. However, sometimes it is necessary to create a sproc in dbA that runs against data in dbB, and in those situations, I recommend using the db name (or code) as a prefix.