Do we really need to differentiate the type of object resulting in a dataset based on consumer usage? Most of the arguments I’ve heard for identifying the kind of object are based around the consumer, such as a reporting tool.
Let’s consider tables and views first. The reason we put together views is so that the consumer does not need to be aware of the underlying data structure. The only time it makes sense to me to know I’m using a view is if it cannot be updated. However, how does that differ from having read only access to a table?
Table Value Functions and Stored Procedures have a different syntax. As a consumer, the reporting tools generally expose the parameters required to consume this kind of data source. Developers really don’t need a prompt. Worst case, a developer can use sp_help to find out what is necessary to communicate with an object. Generally, a prefix for the type of object lends little value.
Depending on your naming convention, there is a benefit to not prefixing your objects with a type. If your naming convention includes something meaningful it is helpful to have a list regardless of type. If you really must have an indicator of type, would it make sense to add that as a suffix instead of a prefix to the object?
That’s probably enough discussion on naming conventions. However, you are welcome to leave comments here to include your insight.
Cheers,
Ben