クリーンなデータベースの設計方法

この記事のような他の記事を読むには、私のブログを訪れてください

名前をシンプルで一貫性を保つための18のベストプラクティス

どんな開発者であっても、たまにこういうAPIに出会うことがあります。データを返す際に、それを理解するのに多くの時間を必要としないものです。

しかし、このようなクリーンで一貫性のある結果を生成するには、時間と努力、そして経験が必要です。今日はクリーンなデータベースを設計するための最初の一歩を踏み出しましょう。

短く要点を絞った内容にしています。さぁ、始めましょう。

用語の説明

テーブル: これはデータの集まりです

プライマリーキー: これはテーブルのユニークな識別子です

属性: あなたのデータのプロパティを意味します。例えば、`name`は`user`の属性です。

データタイプ: データタイプはあなたのデータのさまざまなタイプを表します。例 - 文字列、整数、タイムスタンプなど。

1. 単語はアンダースコアで区切るべきです

属性名に複数の単語がある場合、snake_caseで区切ります。一貫性を保つためにcamelCaseやその他のケースを使わないでください。

悪い例

wordcount もしくは wordCount

良い例

word_count

理由

• 読みやすさが向上する
• 名前をよりプラットフォームに依存しないものにすることができる

2. データタイプを名前として使用しない

タイムスタンプパラメータなどでよくあることですが、データタイプを列名としては使用しないでください。意味のある名前を付けてください。

悪い例

timestamp もしくは text

良い例

created_at もしくは description

理由

• データタイプを使用するとアプリケーションの他のエンドで混乱を招く可能性があります。
• 適切な名前を付けることで、パラメータの使用目的をより明確にすることができます。

3. 属性名は小文字であるべき

属性名に大文字を使用しないでください。

悪い例

Description

良い例

description

理由

• この習慣は、大文字のSQLキーワードからの混乱を避けるのに役立ちます
• タイピング速度の向上にもつながります

4. 単語は省略せずに記述

列名を省略するために工夫することはありません。できるだけ明示的にしましょう。

悪い例

mid_name

良い例

middle_name

理由

• このルールは自己説明型の設計を促進します

5. しかし、一般的な省略語は使用しても良い

ルール4の例外は、広く普及している省略語がある場合です。そのような状況では、短い名前にしてください。

良い例

i18n

しかし、自分自身が混乱している場合は、フルネームにしてください。これは将来のための投資です。

6. 列名に数字を含めない

信じられないかもしれませんが、私は十分にこれを見たことがあります。列名に数字を含めないでください。

悪い例

address1 , address2

良い例

primary_address, secondary_address

理由

• これはあなたの側で非常に悪い正規化の兆候です。なるべく避けてください。

7. 短いテーブル名を使用する

テーブル名を名付ける際には、非常に注意してください。なぜなら、将来的に長いテーブル名が大きな問題を招く可能性があるからです。

悪い例

site_detail

良い例

site

理由

• 短いテーブル名は、関連する列やリンクテーブルを作成する際に役立ちます。

8. 予約語に注意する

各データベースにはいくつかの予約語があります。それらを学び、避けてください。

悪い例

user lock table etc

いくつかの人気のあるデータベースの予約語リスト

• Postgres https://www.postgresql.org/docs/9.3/sql-keywords-appendix.html
• MySQL https://dev.mysql.com/doc/refman/5.7/en/reserved-words.html
• Oracle https://docs.oracle.com/database/121/SQLRF/ap_keywd.htm#SQLRF022

9. テーブル名は単数形

常にテーブル名には単数形を使うようにしてください。これは議論の余地のあるトピックで、異なる意見の人々がいます。しかし、どちらかに統一してください。

悪い例

users and orders

良い例

user and order

理由

• これはプライマリーキーと検索テーブルとの一貫性を促進します
• 複数形は時に厄介なので、単数形を使うことでプログラムが簡単になることがあります。

10. リンクテーブルはアルファベット順であるべき

結合テーブルを作成するとき、2つのテーブルの名前をアルファベット順で連結してください。

悪い例

book_author

良い例

author_book

11. 列名は単数形

通常は、データ正規化のルールを破っていない限り、これが最良の慣行です。

悪い例

books

良い例

book

12. プライマリーキーの名前

単一の列であれば、idとして名付けるべきです。

CREATE TABLE order (
  id            bigint PRIMARY KEY,
  order_date    date NOT NULL
);

13. 外部キーの名前

他のテーブルと関連づけるフィールドの名前が外部キーであるべきです。例えば、team_memberテーブル内でpersonを参照している場合、以下のようにします。

CREATE TABLE team_member (
  person_id     bigint NOT NULL REFERENCES person(id),
);

14. 列名にデータタイプをサフィックスとして付けない

データタイプを列名にサフィックスとして付ける必要はありません。これを避けてください。

悪い例

name_tx

良い例

name

15. インデックスにはテーブル名と列名の両方を含める

インデックスを作成する場合は、参照している列名に続いてテーブル名を含めてください。

CREATE TABLE person (
  id          bigserial PRIMARY KEY,
  first_name  text NOT NULL,
  last_name   text NOT NULL,
);
CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);

16. 日付タイプの列名

日付タイプの列名には、_onまたは_dateをサフィックスとして付けてください。

例えば、更新日を保存する列がある場合、以下のようにします。

良い例

updated_on もしくは updated_date

17. 日付時刻タイプの列名

列名に時間が含まれる場合は、_atもしくは_timeをサフィックスとして付けてください。

例えば、注文の時間を保存したい場合は、以下のようにします。

悪い例

ordered

良い例

ordered_at もしくは order_time

18. ブール型の列名

ブール型の列名がある場合は、is_またはhas_でプレフィックスしてください。

良い例

is_admin もしくは has_membership

最後に

すでにプロジェクトに取り組んでいる場合は、そのプロジェクトで既に遵守している規約に固執してください。なぜなら、

悪い規約よりも悪いのは、複数の規約があることです

しかし、学んでいる最中、またはデータベースをゼロから設計している場合は、これらのルールを念頭に置くことで、長い道のりを進むことができます。

あなたの考えはどうですか？異論があるルールはありますか？コメントセクションで生産的な会話を持つことを非常に楽しみにしています！

素晴らしい一日を過ごしてください！:D

LinkedINで私にコンタクトしてください LinkedIN

私のウェブサイトで他の記事を読む

参考文献
https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/
https://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/mohammadfaisal/how-to-design-a-clean-database-1e83