RDB, 読書

楽々ERDレッスン 読み終わり。

楽々ERDレッスン

とても実践的な内容で私は好き。

業務変更に強いDB設計にはテーブルの「主キーに自動採番のID(サロゲートキー, 代理キー)を設定する」こと、IDによってJOINさせること。コード(ナチュラルキー)ではないことが徹底されて書かれている。

@see

 

なぜIDを主キーにするのか?

正規化の教科書ではコードで連結されるのですが、コード(*ナチュラルキー)は業務体系が変わると変更しなくてはいけなくなる。最初は変更はないとしても、お客様やビジネス上の都合で変更しないといけない時がある。その時にIDを利用していればそういった変更に対しても問題がない。

  • IDを設定することでテーブル間の依存性が弱まり業務の変更に強くなる。
  • IDを利用するので、複合主キーは存在しなくなる。複合主キーを許さない。
  • またFrameworkのORMで自動採番のINT型のIDが採用されていることもあって相性が良い。

 

*ナチュラルキー ・・・ 社員ID, 会社番号, 商品コードなど。自然キーとも呼ぶ。ナチュラルキーは業務に直結しているのでわかりやすいが、業務が変わりコード体系の変更の必要性が生じると変更が大変になる欠点がある。

 

後半はレシートや明細書からテーブル設計をしていく内容で実践的でわかりやすい。

 

テーブルの主キーに自動採番のID(アイデンティファ)を必ずつける

IDを利用することで業務上の変更に強くなる。JOINはIDで行うコード(ナチュラルキー)ではない。

  • IDは一意な座標であり、IDに意味があってはならない。
  • テーブルとの紐づけはIDで行う
  • コードについてはFKとして利用しない。結合はIDで行う。
    そうすることで業務的にコード体系が変わっても変更できる柔軟性がある、コードをFKに利用していると変更できなくなる。

 

事実を記録する

履歴などはシステム的に正しいものではなく、事実を記録する。

  • 売上明細の合計金額
    商品単価 × 個数で算出できるから必要ない?
    実際は割引やセールなどが発生する、
    売上明細については「合計金額」という事実を表す列をつくる。
  • 単価は一つじゃない
    顧客別単価、得意先単価、特別単価、期間別単価・・・など様々な単価が存在する。
    顧客は「単価」と一言でしか呼ばないが、業務の現場では様々な複数の単価が存在する。しつこく聞かないと出てこない、様々な価格に関する事実が存在するケースがある。

 

 

イベント系を見出す、そしてリソース系

  • イベントは「~する」「いつ?」「~日」といった言い方ができるかで見つける。
    見つけたイベントはテーブル化する
  • イベントを見つけてテーブル化したらリソース系を見出す
    「誰が」「何を」でリソース系のエンティティを見出す

 

SQLはバッチ処理

  • すべてのSQLはSELECTに始まり、SELECTで終わる
    ・UPDATEを行う際のWHEREはSELECTで見つける。
    ・テーブルがあるのか検索する際もSELECTが走る。
    内部的にSQLでCRUDのどの処理をするにしてもSELECTが走る。
    →SELECTが走るということはINDEXが重要
  • INSERTですらSELECTを行う
    テーブルの有無、列のデータ型チェック

 

 

遅くなるから非正規化?

  • テーブルを増やすと容量がかかる?
    1レコード256バイトなら1億レコードで24GB。容量は考慮する必要がない。
    ディスク容量の単価が高い時代の話で今は気にしなくて良いし、クラウドなら後から増やすことも容易。
  • JOINが遅くなる?
    今のCPU性能なら気にする必要がないぐらい早い。

正規化は行うべき。

複雑な業務内容だから、それを表現するとテーブル数が多くなるのは仕様がない。

 

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)