無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
「データベースがよく落ちる」「前任者が残したテーブル，SQLが読み解けない」「RDBMSを入れ替えたら予期せぬバグが」――MySQLやPostgreSQLといったRDBMS（リレーショナルデータベース管理システム）を使った業務システム，Webサービスを設計・運用していると，こういった問題によく直面するのではないでしょうか。
本書はRDB（リレーショナルデータベース）の間違った使い方（＝アンチパターン）を紹介しながら，アンチパターンを生まないためのノウハウを解説します。それぞれの章では，問題解決に必要なRDBやSQLの基礎知識も押さえるので，最近RDBMSを触り始めた新人の方にもお勧めです。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
# 現場のミスから学べる、実務的なRDBアンチパターン集
## 面白かったところ
* 歴代の偉大な先輩方が経験された失敗談とその対策がたんまり書いてあり、とても実用的
* 特に `Where狙いのキー、order by狙いのキー` の話は目から鱗だった
* この一冊を買うことによって、守られるプロダクトの平和があると強く感じた
## 感想
インフラ層のミスや失敗談はあるっちゃあるけどなかなか共有されない・知ることが難しいトピック。
可能な限りわかりやすく、時にはデータベースの仕様を織り交ぜながら傾向と対策を謳っている当書にはとても感銘を受けた。
技術的な経験値の有無に関わらず、ITプロダクトに関わる人は一読してもシンはしないだろう。
久々に5つ星をつけたい書籍。
Posted by ブクログ
この本は、データベース設計の失敗例とその解決策を具体的に解説しています。アンチパターンの説明から、それがなぜ問題なのか、そしてどのように解決できるのかまで、一貫して深く掘り下げています。スマートカラム、EAV、削除フラグなど、耳が痛いトピックも避けずに取り上げ、それぞれに対する具体的な解決策を示しています。これにより、読者は自身のデータベース設計を見直し、改善するための具体的なアイデアを得ることができます。また、具体例から始まるため、非常に読みやすく、実践的な知識を身につけることができます。この本は、データベース設計をより深く理解し、自身のスキルを向上させたいと考えているすべての人におすすめです。
Posted by ブクログ
各章の見出しにユーモアとインパクトがあり、またアンチパターンの解説、そしてアンチパターンを生まないためにはどうすればよかったのかをセットで教えてくれるので、なぜ悪い設計のRDBが出来上がるのか、どんな設計をするべきなのかがわかりやすかった。
アンチパターンが引き起こされる事のはじまりは特におもしろく、例えば営業とエンジニアの齟齬からうまれる、
営業「普通追加ボタンがあったら削除ボタンもあるでしょ」
エンジニア「いや追加ボタン一個だけって言ってたじゃん……」
（一章「データベースの迷宮」）
のようなやりとりや、
IDに意味を持たせる設計により、DBの検索がしづらくなる（七章「隠された状態」）など、親しみやすい例が挙げられていた。
データベースのロックやコンフィグ、キャッシュなどはまだわからない部分もあったが、今後もお世話になる本だと思う。初心者におすすめの本。
Posted by ブクログ
実務でもよく見かける例えば「効果の薄いIndex」「多すぎるJoin」「とりあえず削除フラグ」などを例にアンチパターンとその解消方法が紹介されていてとても良かった。
読みながら自分のアプリケーションで場合を考えなら読み進められた。
以下、自分がいいと思った箇所のメモを記載。
### 2章 失われた事実
- 履歴が保存されていることは重要。トラブル対応時に欲しい情報が失われていないか、の観点で履歴の保存は行う
- 例えば、購入した時点の消費税率を、別テーブルで参照しているとき、消費税が変わると、過去にかった金額の消費税率がわからなくなり、返品を行った際に不整合が起きたりする。
- 例えば、配送状態を上書きする仕様にしている場合、過去に配送中だったのか、配送済みになったのか、キャンセルがあったかなどの事実がわからなくなってしまう。
### 3章 やりすぎたJoin
- Joinを多く行うと、テーブルスキャンをする量が指数関数的に多くなり、DBへの負荷も増大する
- 例えば10,000行と10,000行のテーブルのJoinでは100,000,000行のテーブルスキャンがされてしまう。(Indexが貼られていたらその限りではない)
- なのでJoinするテーブルは小さくしてからJoinすることが大事
- Joinには3種類ある
- Nested Loop Join(NLJ)：1行ずつループして処理する
- Hash Join：1度に全件読み込んで処理する(MySQLではサポートされていない)
- Sort Merge Join：全件をソートして上から順に比較する(MySQLではサポートされていない
### 4章 効かないIndex
- Indexが効かない(使われない)ケース
- 検索結果が多い、全体の件数が少ない
- 10,000件のうち9,999件取り出す場合など、Indexの意味がない
- 検索結果が全体の20%未満のとき、総レコード数が数万レコード以上あるときに有効
- 条件にその列を使っていない
- where age + 10 > 20)では無理。 where age > 20 -10 ならできる
- カーディナリティの低い列に対する検索
- Men / Womenしかない場合などIndexは意味ない
- あいまな検索
- where like %keyword% はIndexが効かない。先頭文字がないのでIndexは無理
### 5章 フラグの闇
- とりあえず削除フラグとかは危険。テーブルに「状態」を持たせずに済むならそのほうがいい
- ユニーク制約が使えなくなる(emailをユニークにしたいが、退会済みユーザーとemailがかぶるなど)
- カーディナリティが低いが、検索時には状態を含めて検索する必要が出てきてクエリが遅くなる
- もしテーブルに状態をもたせるならば、、、
- 対象のテーブルが小さく、Indexが不要なこと
- そのテーブルが関連するテーブルの親になることがなく、データ取得の際に頻繁にJoinの対象にならないこと
- Unique制約が不要で、外部キーでデータの整合性を担保する必要がない
### 6章 ソートの依存
RDBMSのエグゼキュータの評価順
1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. HAVING
7. SELECT
8. DISTINCT
9. ORDER BY
10. LIMIT
- ページネーションでOffset100,000とかにすると結局100,000件のデータを見ている。where id > 100000 and みたいにするほうがい
### 9章 強すぎる制約
- 強すぎる制約をかけてそれを変更したくなったとき、Alter文での変更などになるがロックがかかりデータ量によっては結構な時間になるので、メンテナンスの時間を設ける必要もでてくる
- ビジネスロジックに伴う制約は変更される可能性があるので、アプリケーション側でのバリデーションにしたほうがいい
### 10章 ころんだあとのバックアップ
- 毎日バックアップをとっているが、いざ必要になったときにリストアしてみたらリストアできなかったみたいなこともある。バックアップが動いていること、バックアップでリストアできることなどもテストしておくといい。
### 11章 見られないエラーログ
- エラーログが出ていない、エラーが定常的にあって、重要なエラーが何か分からず放置されていることもよくある
※アプリの閲覧環境は最新バージョンのものです。
