みなさま、こんにちは。
ついにMyノートPCを購入してしまいました。 システム担当(?)の杉本です。
中古ThinkPadにUbuntuを入れて利用していますが、外見がボロでもサクサク動いてくれます。
今回は「データベース設計の妙味」と題して、筆者がデータベース周りの設計を行うときに気にしていることをいくつか紹介する。
データベースの設計における基本的事項
データベースの設計というのは、非常に疲れる作業だ。
あれやこれやと書きながら考えると、ガラクタ箱のようDBが出来上がるのだ。
それを防ぐために、以下の様ないくつかの段階に分けて考える。
- 要件を確認する。 (この際、見積もりも参照してDB拡張が可能であるかの判断も行う)
- ある時点で確定している事象や物体を構成する要素を書き出す。
- 要素を書き出したら、共通する項目をテーブルにまとめる。
- 全体をざっくり見て「ここの仕様変更があったらヤバイんじゃね?」というところを探す。
- あとは3と4を繰り返して俯瞰的に美しいと感じられる状態に持っていく。
書き出して見ると大したことないが、実際のところは案件別にある特殊な要件を想定しておくのでかなりの労力が必要だ。
しかしこれができていない場合は、高い確率でコーディングとテストに時間がかかってしまうので、ちゃんとやったほうがいい。
命名どうしよう問題
よんで字のごとしで、名は体を表すことから変な名前つけるとあとで苦労するので、しっかりと意味の詰まった言葉にするべきだ。
注文伝票テーブルに「メールアドレス」という項目があったとしよう。
おそらく、大体の人は「顧客のEメールアドレスかな?」と思うだろうが、いかんせん情報密度が低い言葉であるゆえに誤解を招く恐れがある。
そのテーブルにある日突然「〇〇メールアドレス」とか追加しようものなら、途端にわからなくなる可能性が出る。
もちろん、仕様書とかがしっかり整備されていれば難しい話ではないのだが、そういう設計の場合は仕様書を見てもわからん場合の方がおおい。
テーブル名などは原則として名詞で表現するようにするべきと思う。
本質ってそれなんですか?
事の本質を捉えるのはとても大変だ。
DB設計においては、業務ロジックとの兼ね合いを見つつ柔軟かつ本質を捉えた設計をしなければならない。
これがまた面白いことに正解がないのだ、経験則的に採用するとやばくなる設計(いわゆるアンチパターン)にならなければ、割と自由に捉えてもいいかもしれない。
一言でいうならば
「一つのデータ項目に複数の構成要素をもたせるな」
というところだろう。(多分)
それって….未来も生きていますか?
ここまで来てもまだ不十分なことがある。
それはデータが「どの時点まで有効か?」という点だ。
例えば仮注文データを扱うテーブルがあるとしよう、そうしたときに疑問が生じる。
「いつまでこのデータ生きてるん?」
ということだ。
要件にもよるので絶対的な正解もなければ絶対的な間違えもない。
しかしながら、そのデータのライフサイクルを理解しなければ、バッチ処理なんかで破綻する可能性がある。
非常に簡単に聞こえるが、こちらも疲れるが楽しい作業だ。
おまけ
先日、Steamの秋セールがあったが筆者はフライトシムの機体DLCとETS2のMapDLCを購入してしまった。
まだ、まともに遊べていないのでなんともだが、非常に良き買い物だったと思う。
積ゲーが増えてもかさばらないので、クラウドとは便利なものだ。
勉強しよう GCPとAWS
