命名規則は大切とわかっていてもおろそかになりがちです。
現場の人と要件ヒアリングで忙しい時に、
「この項目名は大文字にすべきか小文字にすべきか？」
という結論がでない議論をしたくないですよね。
そんな時に役に立つルールを紹介します。
命名ルールは開発時や運用時の開発コストに想像以上にかかわってきます。
命名規則はプロジェクトごとに１から作成する必要はないので、このルールをデフォルトとして、細かいところは実情にあわせて使うことをおすすめします。
| AB001X | NG |
| PO_HEADERS_01 | NG |
| PO_HEADERS | OK |
命名規則の一番大切な部分ですが、テーブル名を見て中のデータを想像できないといけません。
たまにあるのが採番台帳で番号をしてその番号を使うというものです。
これはひと目で内容がわからないのでNGです。
数字をいれてるのも内容を判別しにくいので避けてください。
| 注文 | NG |
| TYUMON | NG |
| PURCHASE_ORDERS | OK |
「注文書」といった日本語のテーブル名は使ってはいけません。
日本語の名称を使っても問題のおきないデータベースも多いです。
ですが、問題は外部のソフトです。
データベースにアクセスするソフトに海外の製品を使うことはよくあります。
その時に日本語を使っていたら、文字コードに注意しないといけないなどトラブルを引き起こす可能性があります。
避けれるトラブルは事前に避けるためにも日本語は使わないでください。
ローマ字で書くのは少し恥ずかしいので、調べて英語にしましょう。
| purchase_order | NG |
| PURCHASE_ORDERS | OK |
大文字か小文字で統一します。
「問題がでるか？」
と聞かれたら正直問題はでないです。
ですが人によって小文字だったり大文字だったりと違うと、もやもやしますよね。
ルールを決めとけば問題がでないので、どちらか先に決めておきます。
| PurchaseOrders | NG |
| PURCHASE-ORDERS | NG |
| PURCHASE_ORDERS | OK |
慣習的に_を使っているデータベースが多いです。
データベースの関数に書式をあわせるというのも明確でいいでしょう。
Oracleでは例えば、文字列に変換する関数は「TO_CHAR」です。
その書式に合わせるという考え方です。
統一するのが大切で、セパレータが-だったか_だったかと考える必要がないように統一します。
PurchaseOrderという書き方は「大文字で統一」というルールに反するのでNGです。
| PURCHASE_ORDER_HEADERS | NG |
| PO_HEADERS | OK |
業務単位に大きく分類した時の、英字略称2文字をつけるのがおすすめです。
Purchase Order（発注）の場合PO
Account Payable（買掛）の場合AP
というように英字の頭を使った略称です。
テーブル名を見るだけでどこの業務で使われているのか見当がつき便利です。
この業務単位の分類はスキーマを使うのもいいです。
例えば 「PO.PURCHASE_HEADERS」というふうに書きます。
| PO_REQ_HEADERS | NG |
| PO_REQUEST_HEADERS | OK |
注文モジュール内に、発注依頼のテーブルを作成するとします。
この場合発注依頼を意味するREQUESTは略さないでそのまま使います。
省略すると意味がつかみにくくなるためです。
「モジュールの略称」をつけると矛盾しているのでは？
と感じる人は多いと思います。
一番大きな業務単位は数も少なく、よく業務で使う単語のため略しても意味が通じやすいためです。
第２カテゴリは数も多くなり、業務イメージもつかみにくくなります。
そのため、REQという風に略すると何の言葉の省略形かわからなくなってしまうためです。
| PO_INFORMATION | NG |
| PO_HEADERS | OK |
| PO_LINES | OK |
末尾はテーブル構造の特性でつけます。
テーブルの構造はヘッダーテーブルと明細テーブルに分けれることが多いです。
ヘッダーテーブルでしたら末尾に_HEADERS、明細テーブルでしたら末尾に_LINESをつけるとルールを決めます。
このよくある構造について知りたい方は形で覚えるデータベースのテーブル設計を参照してください。
| PO_HEADER | NG |
| PO_HEADERS | OK |
テーブル名称は複数形で書きます。ヘッダー情報が複数はいっているテーブルだからです。
海外のひとから見ると単数形だと違和感があるということなので複数形にしましょう。
項目名の規則もテーブル名と同じです。
追加で必要なルールを書きます
| ID | NG |
| PO_HEADER_ID | OK |
主キーで一連番号をテーブルに持たせる時にIDという名前にはしません。
PO_HEADER_IDという風に何のIDかを明確にします。
例えば注文ヘッダーと注文明細のテーブルを作るとします。
注文ヘッダテーブル
| 項目名(NG) | 項目名(OK) | 内容 |
|---|---|---|
| ID | PO_HEADER_ID | 注文の一連番号 |
| PO_NUMBER | PO_NUMBER | 注文番号 |
注文明細テーブル
| 項目名(NG) | 項目名(OK) | 内容 |
|---|---|---|
| ID | PO_LINE_ID | 注文明細の一連番号 |
| PO_HEADER_ID | PO_HEADER_ID | 注文ヘッダーの明細番号 |
| PO_LINE_NUMBER | PO_LINE_NUMBER | 注文の明細番号 |
項目名(NG)を見ると、ヘッダーテーブルのIDは明細テーブルではPO_HEADER_IDという項目名になっています。
これはIDの名前が明細テーブルの主キーとして使われてしまっているからです。
ヘッダーテーブルではIDと呼ぶのに、明細テーブルではPO_HEADER_IDと呼ぶというと混乱します。
ですのでIDの名前は使わないでください。
またテーブル同士の関係性を表すER図を作成するときに、項目名が違うと自動作成できません。
そういった意味でもIDは使わないようにします。
IDはテーブル名にあわせるとわかりやすいです。
英字は単数形を使います。
OK: PO_HEADER_ID
NG: PO_HEADERS_ID
| DATE_OF_PO | NG |
| PO_DATE | OK |
末尾のルールを決めます。
あまり細かく作ると不便になるので次の3つぐらいを基本にします。
例）
・_DATE : 日付型の場合はDATEを使う
・_TIME: 時間が必要な場合はTIMEを使う
・_ID：連番の意味を持たない一意の番号にはIDをつける
日付のTIME型とDATE型はトラブルになりやすいので、項目名で区別できるといいです。
例えば発注日が2022年1月31日の注文があるとします。
このときプログラムで <= 2022年1月31日 として抽出したらこの注文は含まれるでしょうか？
答えはTIME型かDATE型かで結果は異なります。
TIME型の場合2022年1月31日10時23分と入っていた場合、2022年1月31日0時0分より大きいので、抽出されません。
業務の項目とは違う、システム上の項目は統一の名前を使い区別します。
例えばデータを作成した日付や作成者の情報です。
| CREATION_TIME | 作成日時 |
| UPDATE_TIME | 更新日時 |
| CREATED_BY | 作成者 |
| UPDATED_BY | 更新者 |
上記の項目はデフォルトで全部のテーブルに追加します。
項目定義書のような形でまとめると次のようになります。
規模が大きいシステムになるほど命名規則はたいせつになるので是非参考にしてください。
テーブルの命名規則
[第１パラメータ] _ [第２パラメータ] _ [第３パラメータ]
| パラメター | 定義 | サンプル |
|---|---|---|
| 第１パラメータ | 業務上の分類の英字略称2文字を使う | PO: 注文業務 Purchase Order SO: 発注業務 Sales Order AR: 売掛業務 Account Receivable |
| 第２パラメータ | テーブルの内容がわかる英語名称を入力する | |
| 第３パラメータ | システム上の分類を書く | HEAERS: ヘッダー LINES：明細 |
項目の命名規則
| 定義 | サンプル |
|---|---|
| 文末文字の規則 | 日付型：_DATE 時間型：_TIME 一意のシステム番号: _ID |
| 予約項目名一覧 | CREATION_TIME UPDATE_TIME CREATED_BY UPDATED_BY |
命名規則に興味がある方は「リーダブルコード」の書籍がおすすめです。
テーブルの命名規則に関係する記述は少ないですが、プロシージャなどプログラムを書くときの変数名の付け方やプログラムコードの書くときに参考になります。
プログラム全般に共通する書き方の本で、プログラマー必須と呼ばれる名著なので、興味があるかたはお読みください。