# 2021-03-11 第6回メンターセッション

## 項目

### MySQLかPostgreSQLか
- PrAha ChallengeでMySQLの理由 → Dockerにあるemployeesのイメージを使いたかった
- Row Level Security という仕組みが便利なので、PrAhaはPostgreを使っている
- 複数テナント間でデータ共有を許さないために使う
- アプリケーションではなくデータベースでセキュリティをかけたい
- マルチテナント・アーキテクチャと呼ばれるアーキテクチャに基づくと、Postgreの方がやりやすい
- Materialized ViewもPostgreSQLにしかないので、これも便利

### RDBを使うべきか、NoSQLを使うべきか
- 初期の立ち上げならNoSQLの方が早い（最初の2週間程度）が、移行するなら面倒
- NoSQLならスケーリングが容易。別サーバーに同じものを置くだけで良いので。
- RDBだとシャーディングによってデメリットが発生する
- 型が決められない場合もNoSQLでも良いのでは？
- 整合性を担保したいような場合はやはりRDB

### サービスの高速化について
- あえてB-Treeではなくハッシュマップを使うケースは見当たらない

バックエンド
1. E2Eのテストベンチなどを使ってAPIとかで遅いところをみる
2. 遅いクエリを確認
3. 無駄なクエリをみる（n+1とか）
4. アルゴリズム的な観点でみる

フロントエンド
- Googleのツールライトハウスを使うと、解析してくれる（かなり便利そう）
- why-did-you-renderを入れておくとReactのレンダリング関連の不具合を見つけてくれる？

### データベース関連のツールについて
- そこまでツールには拘っていない
- 必要なデータを用意する場合は単体テストを書いてしまうことが多い

### NULLはどこまで許容するべきか
- NULLがある場合、まず疑う
- 異なる概念をいっしょのテーブルで扱ってるのではないか？
- 分割した概念をどのタイミングで合わせて取得したいかを考える
- メッセージ付きいいねを例に考える
- 良いねテーブルにNULLABLEなメッセージを追加する
- いいね用のメッセージテーブルを追加する
- ほとんどのケースにおいて、良いねとメッセージ付きいいねは同じ概念だった（アプリケーションで扱うときに分けるならテーブルも分けるべき）
- NULLでもインデックスは働く

### SQLチューニングを体系的、網羅的に学べるブログ、書籍はありますか？
### SQLを書く能力の付け方
- あとで書籍一覧をいただける
- SQLが複雑すぎる時点で、テーブル設計を疑う → SQL力よりテーブル設計力磨いたほうがいいと松原さんは思っている
- PrAhaではテーブルを結構細かく作ることが多いので、SQLが複雑になることは少ない
- 「複雑」とは！？
- サブクエリが入ってきたら、おや？なぜアプリケーション層でやってないのかな
- unionは許せるかもしれない
- どの工程までならテーブル設計は修正できる？
- 本番データが入ってくると、マイグレーションをしなければいけないので、腰が重い…
- テーブル設計が変わってもエンティティが同じならインフラ層以外に変更は不要

### スロークエリ、何秒からスロークエリとするか
- pt-query-digestというツールが便利
- 遅いクエリをランキング化できる
- 長さとか、発生頻度とかの観点でランキング化できる
- mysqldumpslowと似てる

###### tags: `Team-2`