Object naming makes database code self-documenting: a reader should be able to infer an object’s purpose without opening its definition. Names such as SQL01, updateStock, stockUpdate, or sp_orders create ambiguity, turning routine maintenance into investigation. Comments can clarify difficult logic, but they do not compensate for names that conceal what an object does. section 2.2
The stock-update hunt
A bug report says that inventory is wrong after an order. A procedure list reveals both updateStock and stockUpdate, with no reliable indication of which one handles the required process. Inspecting definitions becomes necessary before debugging can begin. In the example, sp_orders calls sp_stockUpdate, whose parameter names make the confusion worse: a stock level is passed as @StockID and a product identifier as @ProductStockLevel. section 2.2
Listing 2.2 Getting the stored procedure definition
SELECT s.definition
FROM sys.objects o
INNER JOIN sys.sql_modules s #1
ON o.object_id = s.object_id #1
WHERE o.name = 'sp_orders' ;
Use the catalog and module definition to identify an unclear stored procedure, but treat this inspection as a cost that clearer names should avoid. section 2.2
Prefer names that state the business action and the thing affected. Renaming procedure parameters from generic or misleading labels to @OrderQty and @ProductID makes the procedure call and its UPDATE statements easier to read. Likewise, sp_updateProductStockLevel communicates more than sp_stockUpdate because it identifies the operation and its target. section 2.2
Apply these naming rules:
- Name an object for its responsibility, contents, or business outcome—not for an arbitrary abbreviation or sequence number. section 2.2
- Make procedure and parameter names agree with the values they accept and the work they perform. section 2.2
- Avoid relying on type prefixes to distinguish objects. SQL Server exposes object type through Object Explorer and sys.objects.type_desc. section 2.3
- Give a view a name that describes its distinct purpose. A view duplicating a table’s columns and meaning raises the question of why it exists. section 2.3
Name the result, not merely the object type
A customers table and a customers view are distinguishable through metadata, but identical semantic names imply identical responsibilities. Rename tables plainly when appropriate, and name a view for the result it presents—such as customerOrders—when it joins customers with orders. This signals that the view is a business-oriented projection rather than a duplicate table. section 2.3
