資料表名稱
命名慣例是一組規則（成文的或未成文的），用來提高資料模型的可讀性。你可以在命名資料庫內的任何內容時套用這些規則，包括資料表、欄、主索引鍵和外部索引鍵、預存程序、函式、檢視等。但你不需要將規則套用到所有資料庫物件。例如，只將命名慣例規則套用到資料表名稱和欄名稱。這全由你的決定，因為使用命名慣例不是強制性的，但仍然有它的好處。本系列文章分為三部分，將介紹一些普遍常用的命名慣例，並講解一些制定你專屬的命名慣例的技巧。第 1 部分文章將介紹資料表名稱，而第 2 部分將重點介紹欄名稱。最後，第 3 部分將介紹其他資料庫物件的命名慣例，例如外部索引鍵、程序、函式和檢視。
為什麼要使用命名慣例
資料庫內極少數只有少量資料表。而事實上，有數百個資料表並非罕見。所以使用命名慣例就能提高模型整體的可讀性並能更容易找到資料庫（DB）物件，助你輕鬆完成工作。
另一個很好的理由是資料庫會隨著時間慢慢不斷地發展變化。儘管通常會避免並僅在必要時才變更其結構描述，但變更資料庫物件的名稱可能會在多方面影響你的應用程式碼。由於你可以預期資料庫將或多或少地保持與其初始時非常相似的狀態，如果你從一開始就選用最佳的做法並在加入新物件時繼續使用它，那麼隨著時間過去資料庫結構都能保持良好的組織。
單數與復數資料表名稱
關於資料表命名的最常見問題之一是使用單數形式還是複數形式。在這個問題上有很多不同的意見。事實上，我們可以看到 MySQL classicmodels 和 sakila 範例資料庫的結構描述都用了這兩種方式命名，前者使用複數資料表名稱，後者使用單數資料表名稱：
如果有助於工作，大多數 DBA 都會使用單數名稱。一個原因是像「user」、「roles」這樣的複數名稱可能會導致一些奇怪的資料表名稱，例如「users_have_roles」而不是「user_has_role」。
描述現實世界的實體
任何時候命名代表現實世界事物的實體時，都應該使用它們的專有名詞。這適用於 employee、customer、city、country 等資料表。通常，一個單字應該就能準確描述該資料表中的內容。
有時你必須使用多個單字來描述資料表中的內容。在 classicmodels 資料庫中可以看到這樣的一個例子。有一個資料表「orders」和另一個資料表「order_details」：
「orders」資料表有客戶 ID、員工 ID、訂單日期、發貨日期、運費和發貨地址等欄位。同時，「order_details」有有關訂購產品的資料，例如訂購的數量和價格。該資料表可以命名為「product_details」，但這並不能表達產品與訂單相關聯。
命名相關資料表
對於兩個資料表之間的關係，標準做法是使用兩個資料表的名稱。還可以在兩個名稱之間加入一個動詞來描述該操作是什麼，例如「user_has_role”」，或簡稱為「user_role」。Sakila 範例資料庫就是使用此慣例，用結合了兩個名稱的中間資料表將相關資料表連接起來。在下面的資料庫模型中，我們可以看到兩個例子——「film_actor」和「film_category」：
關於 SQL 中資料表命名慣例的結語
如果命名慣例在特定情況下沒有邏輯意義，請不要害怕放棄使用它。例如，如果我們有一個 product 和 invoice 資料表，並且我們想要指定哪些產品在哪些發票上，那麼名稱「invoice_item」可能比「invoice_product」或「invoice_contains_product」更有意義。
