# 2021/06/06 メンター相談

###### tags: `メンター相談`,`6月`

## 「作成日時」「更新日時」のカラムの判断はどうされてますでしょうか？

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recwFBY2P6WPri915?blocks=hide

- 個人的にはあまりしないようにしている
- デメリット
- アプリケーション実装者が、間違った意味で使ってしまう可能性がある
- 例: 承認が必要なブログ記事の投稿 updatedAtが自動で更新されてしまう場合、承認を待ってから更新したいのに、勝手に更新されてしまう
- -> 「更新」にドメイン的な意味をもたせたいときに困る
- -> 更新・承認モデルで表現したい状態がずれる
- 「更新日時」は最後のものしか残らないので、調査にもそこまで役立たない
- createdAt, updatedAtは自動で更新される場合があるため、制御しづらい
- メリット
- 後に調査に役立つ

とりあえずで入れてはいけない3つ (考慮すべきユースケースを考慮しきれていないと考えられる)

- 更新日時
- サロゲートキー
- 同一時がどういった時に発生するか（サロゲートキーの意味）などの考慮が必要になる
- 論理削除フラグ
- どういった意味を持つかを考える必要あり

## SQLアンチパターン 幻の第26章「とりあえず削除フラグ」にある、「そもそも削除も更新もしない」とはどういうことでしょうか？

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recyp5CC6ksgrOA54?blocks=hide

### 認識があっているかについて

あっている。(「新規投稿」は無からのupdateと考えることができるので、postとupdateはわけなくてもいいかも)

### イミュータブルな設計を採用したことはあるか？

- ある
- BtoBのWEBアプリ (製造業)の 「[見積もり]の要求」に関するDBで採用した
- -> 見積もりは絶対に更新してはいけないので
- 削除については、削除イベントテーブルを作成。取得時は、削除イベントが発生しているかどうかを毎回確認するようにした
- レコード数は増えるが、インデックスさえはられていれば、パフォーマンス上の問題無さそう

---

最新のステータスを保持するだけのテーブルを作ることも多い

## 「DBモデリング2」の課題について質問です。

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec4IvRDHovAgZw2G?blocks=hide

### レコード数をどのくらい具体化するか、どのようにその値を算出するかについて

- ケースバイケースではあるが、あまりレコード数を考慮にいれて設計することは無い
- -> 大抵はインデックス貼ればなんとかなるため
- -> テストデータを投入し、インデックスの計測を行った
- ライブ配信サービスで、MAX何人くるか、コメント何件来るかを考慮したことがあった
- -> FirebaseRDBの制限に引っかからないかを確認した

---

MAX何人はどこから推測した？

- ライブ予定のアーティストの中で一番人気の人が過去のライブで何人来たかを確認
- その ×5 を想定して仕様を決めた (初回のため、安全に振った)

### ナイーブツリーの設計でもよさそう？

- 松原さんが解いた時はナイーブツリーにした
- スレッドメッセージ: parentMessageIdに親のidが入る
- 大元になるメッセージ: parentMessageIdに自分のidが入る
- nullを入れたくないため
- nullableな外部キーはDBによっては不可能

---

自己参照idが入ることをどう周知した？

- null許容しないことで、なにか入れることを気づかせる
- スキーマの中のコメント
- createするときのコメント
- コメント -> なぜそうしたのかを書くべき、普通と違うことをするときに書く

### その他気になったポイント

threadmessageだけをとってくるユースケースはあまりなさそうなので、テーブルを分ける必要は無いかも？

場合によってはテーブルを分ける場合もある
freee
会計の制度上、年度毎にわけている

## イベントが起こった日時を保存するカラム名はレコードが作られた日時としてcreated_at にしますか？それともイベントにあった日時名を入れることが多いでしょうか？

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec5DPwFF0PJHfOAY?blocks=hide

固有のカラム名にすることが多い
　例: send_message -> send_message_at
クエリ書くときにわかりやすい
delete.created_at <- 分かりづらい

created_at派
joinするときにusing使える

---

textafm第3回

物理設計で初めてパフォーマンスを考慮して妥協する

---

エクストリーム・プログラミングの本

見積もりはどのくらい正確なのか？
実際には2倍かかる