💨

RDB(リレーショナルデータベース) 取り扱い時チェック項目まとめ

に公開

業務していて、何かここ違うなと思ったり、ここはそうじゃないだろう・・・。と思ったことを書いていきます。なお、タイトルは(暫定)なので、これよりもいいものあったら随時更新予定。

この記事で目指すこと

  • 業務or個人開発時に、Tipsとしてすぐに思い出せるようになっておけるようにメモしておく。
  • アウトプットすることで、理解を1つ1つ深めていけるようにする。
  • 身についたものから順にアウトプットし、またまとめたいものが出てきたら都度追加。
  • マインドマップみたいに事象を見て、そういえばこれが・・・と思えるものは都度追加。
  • 最終的に色々な選択肢が頭の中に浮かんで適切な選択・意思決定ができることを目指す。

RDB以外のDBは?

こちらでは特に取り扱わないですが、選択肢として出てくることはあるので比較対象としては出します。また著者が業務でメインで取り扱っていないこともありここでは割愛します。

取り扱いフェーズ

大まかには2つくらいかなと思います。なお(10フェーズ時)以降は、1つのRDBだけにとらわれず複数のサービスにまたがるシステム設計とか範囲が広がってきそうなので省略。ここでは単一のRDBに絞ってまとめておきます。

  • 0 → 1フェーズ
    • RDB作成時
  • 1 → 10フェーズ
    • 既存のRDBが存在し、それを保守開発(集計も含める)するとき
    • 既存のRDBが存在し、それらを運用・監視するとき

フェーズごとに想定されるケース

以下に各フェーズごとのケースを書いてみました。以下は一例なのでケースは随時追加していきますが
今のところで思いつく限りを列挙していきます。(暫定)なので、ここも随時更新予定。

  • 0 → 1フェーズ

    • 新しくテーブルを作りたい。
      • どんなテーブルにする?
        • 使用用途は?
        • どんな粒度で設計・作成する?
          • 【正規化】とか重要なのかな・・・?
        • どんなレコードが入ることを想定する?項目は?
          - どんなSQLを想定する?
        • 過不足のない最適なSQLを想定するとどんな感じ?
          • パフォーマンスの検討が必要そう
  • 1 → 10フェーズ

    • 既存のSQLに改修を加えたい。
      • 現状はどうなっている?
        • 状態管理のあり方として適切になっている?
        • クエリが複雑すぎるがそもそも適切?
      • どう改修を加える?
        • 新規に作成する? or 既存のSQLを修正する?
    • 既存のレコードが含まれている状態をもとに集計したい。
      • 何を集計する?どんなものを集計する?いつ集計する?

参考にする書籍(現時点)

  • 失敗から学ぶRDBの正しい歩き方 (Software Design plus)
  • SQLアンチパターン(オライリー)
  • 達人に学ぶdb設計徹底指南書 第2版

Discussion