テーブル名、カラム名をつけるときの参考に。
JOE CELKO’SSQL PROGRAMMING STYLE
https://www.amazon.com/dp/B006L21AO6/
PDF
http://index-of.es/Databases/mssql/SQL%20Programming%20Style%20-%20Apr%202005.pdf
1 名前とデータ要素
1.1 カラム名、テーブル名
長さ,SQL-92=30、SQL-99=128、MySQL=64、Oracle=30、MSSSQL=128
大文字、小文字、数字、アンダースコア(記号を使わないこと)
クオート文字は、「”」(ベンダー特有の記号を使わないこと、MSの「[ ]」など)
1.2.1 スカラー変数名
ISO-11179-4
1.ユニーク(表示されるデータ辞書内)。
2.単数で述べる。
3.それが何ではないかということだけでなく、そのコンセプトが何であるかを述べる。
4.記述的なフレーズまたは文として記載する。
5.一般に理解されている略語のみを含む。
6.他のデータの定義を埋め込まずに表現する。
または基本的な概念です。
7.テーブル、セット、その他のコレクションには、クラス、または複数の名前。
8.手続きには、その名前に動詞を持たなければならない。
9.テーブルのコピー(エイリアス)は、ベーステーブル名をその時に果たしている役割と同じように。
1.2.3 プリフィックスのアンチパターン
× tbl_xxxx テーブル名にtbl_接頭辞を使ってはいけない
× テーブル名を接頭辞に使ってはいけない。特に、<テーブル名>_id は最悪。
次に悪い接辞は<テーブル名>です。 データ要素がなぜテーブルごとにまったく違うのでしょうか? 例えば、「orders_upc」と「inventory_upc」はどちらもUPCコードです。2つの名前があることで、データモデル内で論理的に異なるものになってしまいます。
そして、クエリは「Orders.ID = OrderID」のようなコードでいっぱいになります。
まじー?誰も守っていないよ?
「<テーブル名>_id は最悪」の真意がわからないわね。
Ordersテーブル自身のIDは、order_id として、Orders.order_id = Foo.order_id としたほうがいいって意味かもしれないわね
× ビユーの接頭辞に vw_ を使ってはいけない。
× データ型を使ってはいけない。intorder_nbr
× 主キーに PK_、外部キーに FK_
× ストアドプロシジャの usp_、トリガーの trig_、
1.2.4 標準ポストフィックス
(原文:Teradata's internal standard and common useからとのことですが、見つかりませんでした)
ポストフィックス | 意味 |
---|---|
_id | |
_date, _dt | 日付 |
_nbr, _num | 数字。_no を使ってはいけない |
_name, _nm | 名前 |
_code, _cd | idと混同しやすいが、codeは外部でメンテされているコード、例:郵便番号。 |
_size | 工業標準 |
_tot | 合計 |
_seq | シーケンス、順序番号。ギャップを持たない、タグ番号とは違う。 |
_tally | 値のカウント、絶対スケール。数を数えるとき日本語では「正」、英語では、縦棒4本+横棒1本で数える、これをtallyと呼ぶ。 |
_cat | カテゴリー、正式な基準のある、外部ソースのある。区別される。複数カテゴリーに所属しない。例:動物、野菜、鉱物 |
_class | 正式な基準のある、外部ソースのない。カテゴリー内のサブカテゴリー。例:動物を哺乳類や爬虫類に分類する |
_type | クラスよりも正式ではない。内部、外部ともに共通の意味を持つ。例:モーターサイクル、自動車、タクシー |
_status | 状態の内部エンコーディング |
_addr, _loc | addressは住所、locationは場所 |
_img | 画像 |
1.2.5 テーブル名とビュー名:業界標準、集団、クラス、または複数の名詞でなければならない
1.2.6 エイリアス名:テーブル名、カラム名の命名規則にしたがう
1.2.7 リレーションテーブル:関係に一般名があればそれを利用する。
○ Marriages
× ManWoman, HusbandsWives
○ Enrollment
× Students_Courses
1.2.8 メタデータスキーマ
○ _idx
1.3 データ要素
1.3.1 あいまいな名前を避ける
× CREATE TABLE TblColors
(color_value_id INTEGER NOT NULL PRIMARY KEY,
color_value VARCHAR(50) NOT NULL);
○ CREATE TABLE Colors
(pantone_nbr INTEGER NOT NULL PRIMARY KEY,
color_description VARCHAR(50) NOT NULL);
1.3.2 テーブルによって異なるカラム名を使ってはいけない
× xxx.URN yyy.IPCURN, zzz.OffenceURN
○ xxx.urn, yyy.urn, zzz.urn
1.3.3 独自の物理ロケータを使ってはいけない
IDENTITY, GUID, ROWID, 他の自動番号付け
2 フォント、スペース
2.1.1 大文字、小文字、数字、アンダースコアのみを使うこと
2.1.2 カラム名、変数:小文字
2.1.3 キャピタル:テーブル名
2.1.4 大文字:予約語
2.1.5 キャメルケースを使わない。
○ SELECT hoge_hoge AS h FROM Hoges;
× select hogeHoge as h from HOGES;
2.2 SQL文のスペース
○ foobar = 21
× foobar=21
2.3 カンマ後のスペース
○ SELECT a, b, c
× SELECT a,b,c
2.4 省略可能な予約語でも省略しないこと
文脈によっては、yyy AS y の AS を省略して、yyy y と記述可能だが、yyy AS y と書いたほうがよい。
○ yyy AS x
× yyy x
2.5 標準予約語を使えるなら、独自予約語を使ってはいけない
2.6 標準ステートメントを使えるなら、独自ステートメントを使ってはいけない
2.9 適度に空行を挿入する。
3 Data Declaration Language
3.1 DEFAULTを最後に
3.2 DEFAULT値はデータ型と同じもの
3.3 独自データ型を使ってはいけない
3.4 PRIMARY KEYをCREATE TABLEの最初に
3.5 カラム順序は論理的な順序にする
3.6 ON DELETE句、ON UPDATE句を別々の行に書くこと
3.7 CONSTRAINT句に名前を付ける
3.8 CHECK()制約を対象列の近くに書く