テーブル名
命名規則は、データモデルの可読性を向上させるために利用する必要がある一連の規則（記述または非記述）です。これらの規則は、テーブル、列、プライマリキーと外部キー、ストアドプロシージャ、関数、ビューなど、データベース内のものに名前を付ける時に適用できます。全てのデータベースオブジェクトに規則を適用する必要はありません。例えば、命名規則のルールをテーブルと列の名前に限定してもまったく問題ありません。命名規則を使用することは必須ではありませんが、それでも有益であるため、それは本当にあなたの決定です。この3部構成のシリーズでは、一般的に使用される命名規則を紹介し、独自の命名規則を作成するためのヒントを提供します。パート1ではテーブル名について説明し、パート2では列名に焦点を当てます。最後に、パート3では、外部キー、プロシージャ、関数、ビューなどの他のデータベース オブジェクトの命名規則について説明します。
命名規則を使用する理由
データベースにあるテーブルが少数であることはめったにありません。実際、何百ものテーブルがあることは珍しくありません。命名規則に従うことにより、全体的なモデルの読みやすさが向上し、データベース（DB）オブジェクトを見つけやすくなるため、作業がずっと楽になります。
もう1つの正当な理由は、データベースが時間の経過とともにゆっくりと進化することです。通常、スキーマの変更は避けられ、必要な場合にのみ行われますが、データベースオブジェクトの名前を変更すると、様々な方法でアプリケーションコードに影響を与える可能性があります。データベースは多かれ少なかれ原型と非常によく似たままであることを期待できるので、最初からベストプラクティスを適用し、新しいオブジェクトを追加する時にそれらを使い続ける場合、データベース構造を適切に整理された状態で長期間維持できます。
単数形と複数形のテーブル名
テーブルの命名に関して最もよくある質問の1つは、単数形と複数形のどちらを使用するかということです。この問題については、様々な意見があります。実際、MySQLのclassicmodelsとsakilaサンプルデータベースのスキーマで表示された両方のビューを見ることができます。前者は複数形のテーブル名を使用し、後者は単数形の名前を使用しています：
それが役に立つ場合、ほとんどのDBAは単数形の名前を使用します。理由の1つは、「users」「roles」などの複数形の名前が、“user_has_role”ではなく“users_have_roles”などの奇妙なテーブル名につながる可能性があることです。
現実世界のエンティティを説明する
現実世界のものを表すエンティティに名前を付ける時はいつでも、固有名詞を使用する必要があります。これは、employee、customer、city、countryなどのテーブルに当てはまります。通常、そのテーブルの内容を1つの単語で正確に説明する必要があります。
テーブルの内容を説明するために複数の単語を使用しなければならない場合があります。そのような例の1つは、classicmodelsデータベースで見ることができます。"orders"用のテーブルと"order_details"用のテーブルがあります：
"orders"テーブルには、顧客ID、従業員ID、注文日、発送日、運賃、発送先住所などのフィールドが含まれています。一方、“order_details”には、注文された数量や価格など、注文された製品に関するデータが含まれています。フィールドに“product_details”という名前を付けることもできますが、それでは製品が注文に関連付けられていることがわかりません。
関連するテーブルの命名
2つのテーブル間の関係については、両方のテーブルの名前を使用するのが標準的な方法です。両方の名前の間に動詞を追加して、そのアクションが何であるかを説明することもあります。例えば、“user_has_role”、または、単純に“user_role”などです。Sakilaサンプルデータベースは、関連するテーブルを両方の名前を組み合わせた中間テーブルと結合することにより、この規則に従います。以下のデータベースモデルでは、“film_actor”と“film_category”の2つの例を確認できます：
SQLのテーブル命名規則に関する最終的な考え
特定の状況で論理的に意味をなさない場合は、命名規則から逸脱することを恐れないでください。例えば、製品と請求書のテーブルがあり、どの製品がどの請求書に記載されているかを説明したい場合、“invoice_product”または“invoice_contains_product”という名前よりも“invoice_item”という名前の方が適切な場合があります。
