0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

システムを考慮したテーブル設計について

0
Posted at

挨拶

初めましての方は初めまして!お久しぶりの方はお久しぶりです!
最近は、ダイエットに勤しんでいるミツクマです🐻
今日は業務でテーブル設計を行ったので
その中での気づきや頂いたアドバイスを自分なりに昇華して
記事にしていきたいと思います。

テーブル設計において必要だと思うこと

私が業務の中で気づいたり教えてもらったりした中で
大事と思ったのは以下の~点です。

  • 中間テーブルの存在
  • データ型の考慮
  • ORマッパを考慮したテーブル定義

命名規則や第一、二、三正規など基本を抑えた上で大事だと思いました。

中間テーブルのが存在

初めて、テーブル設計を行いとにかく第三正規化しなきゃ!!と思っていた私にはとても
大事な箇所だと思いました。
特に何も考えていなかった私はLeft outer joinで良いんじゃね?と軽く見積もっていました。
実際は、何かしらの履歴を参照する際にはテーブルとして情報を保持しておきたいと要望を頂き
どうするべきか頭を悩ませていました。
そこで上長から、中間テーブルを教えてもらいました。
これにより、複合ユニーク制約やインデックスなども覚える事ができました。

データ型の考慮

これについては、仕様や拡張性を考慮すると一言で片づけれるのですが
一例として、残します。

  • 例1:
    有効・無効などはステータスとしてintと最初設定したのですが、
    "オン・オフや有効・無効など確実に2つしか状態がないのであればbooleanを設定するべき"と教えて頂きました。
    そりゃ確かに…( ノД`)

  • 例2:
    複数ステータスがあるものに対して、Stringを設定したのですが
    "バックエンド側でenumを作って処理することができるのでintで大丈夫ですよ"と教えて頂きました。
    これについてはケースバイケースなのかな?と思っていますが
    有識者の方に詳しく聞きたいところではあります。

僕の低能さを露呈しただけの例かもしれませんが、ただテーブルを作るのではなく連動するバックエンドやインフラ周りも
視野に入れてデータ型は決めるべきと思いました。

人工キーの重要性

"高度なORマッパー(SQLを書かないもの)などには、シーケンスなPKを設定する必要がある"と教えて頂きました。
これも先ほどの話と被る部分ではあるのですが、学生の頃では知る機会がなかったので抜き出しました。
それからは登録する際にAUTO_INCREMENTで連番を振り、それを主キーにするようにしました。
確かに、主キーが一つで済むし、繰り返し処理を行う際も簡易的にコードを組むことができるようになりました。

いかがでしたでしょうか。
私なりのテーブル設計時に必要なことをまとめてみました。
私より更なる高学者の方々が、深いところを解説してくれる記事はあるので
私は私なりに浅瀬を掘り下げてみました。
初学者の方や僕と同じような新米エンジニアの方の役に立てればと思います。
それでは、ミツクマでした!🐻

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?