列名
SQL命名規則についての第2回へようこそ。 パート 1 で説明したように、命名規則は、データモデルの可読性を高めるために利用すべき一連のルール（明文または不文）です。これらは、テーブル、列、プライマリキーと外部キー、ストアドプロシージャ、関数、ビューなど、データベース内のほぼあらゆるものに適用できます。パート 1でテーブルの命名規則を説明したので、今回は列名について見ていきます。プロシージャ、関数、ビューなどの他のデータベースオブジェクトについては、パート 3で説明します。
プライマリキー列n
プライマリキーは、テーブル内のレコードを一意に識別するテーブル内の1つのフィールドまたはフィールドの組み合わせです。テーブルにはプライマリキーを1つだけ持つことができます。そのため、多くのDBAは、この列に単純に“id”という名前を付けることを好みます。他には、Sakilaサンプルデータベースに見られるように、テーブル名に“_id”接尾辞を追加します：
同様に、PK制約にも意味のある名前を割り当てる必要があります。プライマリキー制約の命名規則では、接頭辞“pk_”の後にテーブル名が続きます（つまり、“pk_
外部キー列
外部キーは、他のテーブルのプライマリキーを参照するテーブル内のフィールドです。従うべき良いルールは、参照されるテーブル名と"_id"を使用することです。例えば、customer_id、employee_idです。これは、フィールドを外部キー列として識別し、参照されるテーブルを示すのにも役立ちます。
これは、countryテーブルのcountry_idフィールドへの外部キーを含むcityテーブルです：
外部キー制約の命名規則では、接頭辞"fk_"、その後にターゲットテーブル名、その後にソーステーブル名が続きます。したがって、構文は"fk_<target_table>_<source_table>"である必要があります。
cityテーブルの外部キー制約の命名規則に従うと、"fk_city_country"という名前が付けられます。
データ列
第1部の”現実世界のエンティティを説明する”のセクションでは、次のように述べられています：
現実世界のものを表すエンティティに名前を付ける時はいつでも、固有名詞を使用する必要があります。これは、employee、customer、city、countryなどのテーブルに当てはまります。通常、そのテーブルの内容を1つの単語で正確に説明する必要があります。
同じルールをデータ列にも適用できますし、適用する必要があります。繰り返しになりますが、その列に格納される内容を説明するためには、country_name、country_code、customer_nameなど、最小限の単語を使用する必要があります。2つのテーブルに同じ名前の列がある場合は、名前を一意に保つために何かを追加できますが、テーブル接頭辞によってクエリ内の列が区別されるため、厳密には必要ありません。それでも、各列に一意の名前を付けると、後でクエリを作成する時にこれらの2つの列を混合する可能性が減るため、役立ちます。customer_name city_nameのような名前は、複数のテーブルに出現する可能性があります。それが気になる場合は、order_customer_nameやcity_of_residence_nameなど、いつでもわかりやすい名前を付けることができます。
日付
日付の場合、その日付が何を表すかを説明することをお勧めします。start_dateやend_dateのような名前は非常に一般的で汎用的です。call_start_dateやcall_end_dateなどの名前を使用すると、より正確に説明できます。
列名の命名規則に関する最終的な考え方
おそらく、提示された全ての例から、テーブル名と列名はどちらも小文字で単語をアンダースコア（"_"）で区切る必要があることに気づいたでしょう。例えば、customerNameやinvoiceDateではなく、customer_nameやinvoice_dateです。これは、コードの可読性を高めるために、ステートメント名、句、その他のキーワードを大文字にするSQLスタイルの規則とうまく機能します。例えば、SELECT customer_name, invoice_date FROM orders;
