雑多に思ったことメモ

• DBMS→Databese Management System

  • 毎回これ忘れるんだよなw

• データ(データベース)設計が重要な理由

  データ設計がシステムの品質を最も大きく左右する。ソフトウェアというのは、言ってみれば「データの流通機構」であって、どのようなプログラムが必要になるかは、どのようなデータをどういうフォーマットで設計するかに左右される。

  それはそう。今やってるPBIはドメインモデル(概念モデル)設計→データベース設計って感じでウォーターフォールで丁寧にやったけど、ここでいうデータ設計はドメインモデル設計も含まれていそう。そういえばドメインモデル(概念モデル)を設計してからDB設計した方が本質的な構造を設計しやすいというゆっきーさんからの助言があったが、だいぶ大きなラーニング

  by チャッピー

  1. 抽象度が高いほど、より本質的な構造に近い

  • 概念モデル → 論理モデル → 物理モデルの順に、抽象度が下がっていきます。

  • 抽象度が高い概念モデルは、技術的な制約やRDBMS固有の仕様から自由で、本質的なデータ構造や業務ルールを捉えることができます。

  例：顧客は商品を注文する、という「ビジネス上の関係性」は、テーブル名や主キーとは無関係に存在する本質的な構造。

• DOAとPOA

データ中心アプローチ(Data Oriented Approach(DOA))が主流

最初にデータがある。プログラムはその次にできる

データの形式等が先に決まっていれば業務要件に柔軟に対応できると。というか、逆で考えるとPOAでプロセス(アプリケーションコード)中心に進めちゃうと、業務処理の頻繁な仕様変更に弱いのか。データを個別で持つことになったり、ドメイン設計を怠った状態で進めて、仕様変更起きて、出戻りの影響範囲大きくて、みたいなイメージ。ドメイン設計とテーブル設計をガチガチにした方が長期的に利益が大きいだろうし、まさに品質担保に最適。

bara-sanとの1on1でAP領域で色々悩んでることがありそうだったけど、こういうところのプロセスの違いが昔起こっていて、それを今モロに影響くらってるとかなのかなあ

• 論理設計

論理設計のステップ エンティティの抽出→エンティティの定義→正規化→ER図の作成

これって、組織図のPBIでやった通りでいくと

要件定義・イベスト→ドメインモデル設計→テーブル設計→ER図(マーメイド化)みたいなことかしら。若干違いそうな気もするけど笑

• 物理設計に「インデックス設計」があるけど、明示的にあるものなんだ

• レプリケーションが出てきた。

  • リードレプリカで負荷分散とか障害発生時に対応するとかのことをここで言ってるんだろうが、BOでレプリケーションってどこで行われているものなんだろ。存在を知らないかも

• 第二正規化でテーブル分割できてた。同じ責務・同じ値が入っていたらそれは分割しようねって話。

  • 例えば社員テーブルに「会社コード」と「会社名」があるとき、おそらくそれらはお互い紐づいて同じく一意なので、社員テーブルにあるより、会社テーブルに新しく切り出そうね的な話。

    • こうじゃないと困る・不便なことが2つ

      • 一つは社員テーブルに、「社員の情報は不足しているけど、会社名だけは一旦登録できる」見たいな時に、そのインサートができないこと。ダミー値を使って回避する方法もあるらしいけど、それはしんどいな

      • もう一つは、まちまちになって一つのテーブルに関心ごとがたくさんあると、仮に会社名が重複したり運用ミスでダミー値に誤った値を入れてしまう可能性があるかつ、アプリケーション側でチェックロジックを多く書かなければいけない。確かに。

相手のエンティティと対応するレコード数をカーディナリティと呼びます

そうなんだ知らなかったw

• IE記法でしかER図書いたことない。IDEF1XでER図は書いたことないな。見たことはたまにある

• 正規化と非正規化ってマジでトレードオフだよな

  • 正規化はテーブルをいい感じに分割したりするので責務は分かれていてぱっと見良さそうと思うけど、取得や更新は確かにSQL複雑になる時多いし、かといってBOで非正規化された、要はテーブル1つに何もかも入ってるみたいなのはまだあまり見たことないな(UMだけしか経験ないけど)

  • パフォーマンスや検索SQLは考慮する必要ありそうだけど、あくまで非正規化は最後の手段という認識

• 更新時のパフォーマンスや改修コストの大きさも考慮すると、やはり論理設計には物理設計の力も必要で、DB周りもSQL周りも勉強しないとなああのお気持ち

• インデックス便利ですよねえええ

  • B-treeのインデックスしか知らなかった。いろんな種類あるんだ

    • データ量が多ければ多いほど、フルスキャンより有利と。

    B-treeインデックスはどの列に作るべきか

    • 大規模なテーブル

    • カーディナリティの高い列

    • SQLでWHERE句の選択条件、もしくは結合条件に使用されている列

    データ量が少ない時はインデックスを貼らない方が早いと思うので、後からつけるとかもあるのかなとか思ったんだけど、どうだろ

  • 主キーと一意制約の列には自動でインデックスが付与されているという衝撃の事実

    • 確かに貼ろうとしたことなかったし、いつも貼ってないけど、これを聞くと、「あ、そういうことか」ってなった

  目安としてレコードが10万以下の場合はほぼ効果がない

  え、そうなんや。だいぶ大きくないと効果ないんだ。無闇に貼るもんじゃないな。BOだとユーザー数的にすぐ貼っちゃっていいだろうけど。個人開発とか、いらんやん

  定期的なメンテナンスの中でインデックスを途中から貼るとかが良さそu

• パーティションってBOどっかでやってるのかな？自分がやったことないから見てみたい

  • パーティション上限あるの！？この書籍曰くポスグレは上限100程度らしい

• アンチパターンの事例の一つで、「多すぎるテーブルをまとめたい」というセクションがあった

  • やってしまいそう。分けすぎてもしんどいし、構造変わらんし、単一参照テーブルでいいんじゃないかと一つのテーブルにまとめてしまいそう。

  • 結論。スケーラビリティに欠けるので、極力分けよう。正規化というやつですな

  • 単一参照テーブルの利点欠点↓↓

    • バグに気づきにくいは本当そう

• ダブルマスタが起こってしまうケースってこういうことかあああ。BOそんなことあるのかな。

全体の感想

本質的な構造を設計するにあたって、ドメイン設計なりテーブル設計に工数を多く割くのは大事と言うのは最近知ったこと。学生時代の個人開発とか特に、まず動けばいいし、それほど規模が事業レベルまで莫大になることもないし、そうするつもりもなく作っていたので、ある程度ならテーブル設計は適当にしても誰も困らないし、開発者が数十人でやることもないのでそこまで厳格にやらないでよかった。

最近はPBIでテーブル設計やドメイン設計に携わらせてもらって沢山学びがあるけど、凄い楽しいし、設計は開発に安心感を与えてくれる。全てに意思意図を持つのは実は大変なことで、でも意思意図がないと、当時なんでこうしたか、変更したいけど意思意図があるかもしれず、変なとこでバグを起こしてしまうかもしれないという不安からも、いろんな意味で変更しずらい。その積み重ねが負債となり、将来の開発者に負担をかけ、それが事業インパクトに負の影響をもたらす。こう考えれるのは、BOという爆速で大きくなっているプロダクトでこそ経験できることだなと感じる。

こっしーさんと雑談ベースで会話していた時に、「個人開発とチーム開発で違うはもちろん、10人で開発と、BOのように70人で開発も、全く違う」というのがわかった。こういうことですよね。設計に時間をかけ、将来の開発者が気持ちよくスケールしていけるプロダクトがYOIですね。とはいえ、スピード感とのトレードオフがあるので、ここが判断難しいところなんですよねえ。。。。

この本で書かれたDB周りの知見は程よくインプットできた。どちらかというと、この本を読んだ上で、設計は改めて大事と思うのと、知識として蓄えられたものはあったけど、それ以上に感じることは上で書いたBOの現在地についてって感じだった。。。まだ社員として入って2ヶ月だけど。。。。 ww

カオスな地帯にもしないために、みんなで設計して快適な開発環境を作っていきたいと思わせてくれる本でした