スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

データベースの設計 テーブルやカラムの命名規則 2/2

前回に引き続きデータベースの命名規則についてまとめる。

データベースの話の前に、いろいろ調べると命名規則に関して専門用語(?)があったので簡単に触れる。

■snake case スネークケース
文章をアンダースコアで区切る記載方法
例)hello world → hello_world

■camel case キャメルケース
単語の先頭の文字を大文字にして区切る記載方法
例)hello world → helloWorld (camel notation キャメルノーテーション)
例)hello world → HelloWorld (upper camel アッパーキャメル)
※ちなみにキャメル=らくだ。文字の並びがでこぼこしてらくだのコブのようだからこう呼ばれるらしい。

上記はこのあと出てくる用語。


ではデータベースの命名規則に関して、下記の記事をみつけたのでまとめてみた。
Database Naming Convensions


一般規則


・すべての名前はキャメルノーテーションにすべき

-- 良い例 --
user
permision
userPermission

-- 悪い例 --
User
Permission
User_Permission
user_permission




・名前にはキャメルケースを使い、アンダースコアやスペースは使わない。こうすると読みやすくなるだけではなく、SQLの命令を書く時にクォーテーションをつけなくてもすむ
・接頭語や名前空間のみアンダースコアで区切ってもいい。こうすると区切りが明確になる。

-- 良い例 --
blog_user
blog_userPermission

-- 悪い例 --
BlogUser
BlogUserPermission
Blog_UserPermission




・名前に数字を利用するのは良くない
・名前に.(ドット)は利用しない
・データベースの予約語は利用しない
・目的がわかるようなネーミングにすることを心がける
・略語は出来る限り利用しない。一般的なもののみ利用してもよい。
・頭字語(KFCなど、頭文字を並べた単語)は出来る限り利用しない。一般的なもののみ利用していいが、その際は大文字を利用する

-- 良い例 --
HTTPRequests
savedURL

-- 悪い例 --
http_requests
httprequests
savedurl
saved_url




テーブル規則


・テーブルは普通、永続的なものとして作られる。その為、しっかりとした英語で自然な意味を持つようにしたい。こうすることで意味の通じるものになる。
・頭字語と略語は出来る限り利用しない。利用する場合は上記と同様、キャメルケースや大文字を利用する。
・複数形は利用しない。複数形か単数形かを混同したエラーを避ける。

-- 良い例 --
blog_user
blog_page
person
box
activity

-- 悪い例 --
blog_users
blog_pages
people
boxes
activities




・グルーピングが必要であれば名前空間を利用する。こうすることで複数のテーブルを利用する時に明確になる。名前空間と後続の名前はアンダースコアで区切るが、後続の名前はキャメルケースを利用する。

-- 良い例 --
lookups_country
lookups_state
lookups_regionalOffice
hr_employee
hr_salary
is_employee
is_vacationDay

-- 悪い例 --
LookupsCountry
lookupsState
LOOKUPS_RegionalOffice
HREmployee
ISEmployee
ISVacationDay




・tblやdbなどの接頭語は冗長であり無駄なので使わない
・すべてのテーブルは少なくとも1つのプライマリーキーが必要


カラム規則


・カラム名はっかりとした英語で自然な意味を持つようにしたい。こうすることで意味の通じるものになる。
・頭字語と略語は出来る限り利用しない。利用する場合は上記と同様、キャメルケースや大文字を利用する。
・プライマリーキーや外部キーはIDという接頭語を利用して命名する。ただ単にidというカラム名は作らない。テーブル名に則した形で意味の通じるものにする。

-- 良い例 --
userID
userPermissionID

-- 悪い例 --
id
userid
upid




・外部キーはFK_という接頭語を利用する。これにより視覚的にリレーションを表しテーブル選択時の曖昧さをなくす。FK_のあとは前述の規則に従う

-- 良い例 --
FK_userID

-- 悪い例 --
fkuserid
userID




・ブーリアンのカラム名はisから始める

-- 良い例 --
isActive
isSold

-- 悪い例 --
active
sold




・日付のカラムはDateをキャメルケースで記載する

-- 良い例 --
createdDate
updatedDate

-- 悪い例 --
date_created
date_updated




ということで、どれも理由がしっかりしている規則だった。
こういうところを守ればその後作成されるコード(このテーブルを利用する参照元)がより明快になるのだと思う。


[PR]

コメント

コメントの投稿

非公開コメント

PR

PR

プロフィール

何でも書くman

Author:何でも書くman
思ったことや備忘録など、とりあえずなんでも書きます。IT系のことや趣味、生活に関わることなども。

ページの先頭へ戻る
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。