TL;DR

アプリケーションエンジニアもバックエンドの知識はあった方が面白いよ。
いつどんな仕事が舞い込んでくるか分からないから守備範囲決めずに自己研鑽しようね。
アンチパターンは実例としてわかりやすい。
ストレージは、冗長設計しようね。
良書でしたので、是非いろんな方に読んで欲しい。(ステマじゃないよ)

簡単な自己紹介

iOS, Androidのモバイル開発を主に行なってるエンジニア3年目です。
今所属しているチームのリソースの関係でアプリに拘らずバックエンドの開発業務も舞い込んでくるのでそっちの知識も最近は積極的に取り入れています。

今回DBに関する書籍を読んだので、アプリエンジニアが知っておくメリットみたいな視点もなるべく取り入れながら、簡単な書評を中心に記事を書いていこうと思います。

書くこと

参考書の書評
アプリケーションエンジニアがこの本を読んで学べること
＊ばちばちのインフラ屋さんはちょっと物足りない記事だと思います。

書かないこと

業務レベルでDBを設計・運用する上での知識技能
＊本書では論理設計に関してはかなり実用的な部分を学べます！

参考書籍と難易度

難易度参考：★★★☆☆
達人に学ぶDB設計~徹底指南書~

DBに関する知識を取り入れようと書籍を漁るとGoogleから必ず上位に提示されます。
レビューとか読んでいても脱初心者を目指す本みたいなので、ある程度基礎知識はあった方が読みやすいかなという印象はありました。

私も応用情報技術者は持っているので、あー懐かしい単語だなと思いながら読み進めていました。全くの初心者が読み進めるのは少し効率が悪いかもしれません。
ただ、説明も細かく文章もこれ業務で使わないから割愛するよとか書いてくれるので読みやすい構成でした。
（各章の最後に登場する演習は超絶微妙。。）

大事なこと

本書の中をアプリエンジニアの立場で読んでいて印象に残った部分を抜粋していきます。
では、いってみましょー

一貫して伝えたいこと

大体、書籍で伝えたいことは「はじめに」や「第1章」に集約されているが、本書ではデータひいては、DBが登場しないシステムはあり得ないということだ。
どのような規模のシステムだとしても必ずデータフローは存在するし、今日ではビックデータの活用と言われているくらいにデータの価値は高まっている。

そういう側面で見ても、やはりインフラ屋以外がDBやバックエンドに関して学ぶことには大きな価値があるのではないだろうか。
~~ぶっちゃけ、ネットワークとかの方がアプリの知識としては使うので、優先度は高いけど~~

DOAとPOA

DOA: Data Oriented Approach
POA: Process Oriented Approach
単語は正直覚えなくてもいい気がするが、(デスペとか受ける人は覚えた方がいいかも)

要は、システム設計をする上で最近はまずはデータを中心として設計し、その後に処理（プログラム）を書いていくDOAが主流ですよということ。POAは手順が逆になります。

これは実務に携わっている若手なら特に、当たり前じゃない？と思うかもしれないが、一昔前のベテランエンジニアや初心者はPOAの方がすっとはいってくるのだろうか。

私はデータありきでないと、拡張性や可用性の担保が難しいなというのが直感的に思ったところなので、違和感はなかった。

ストレージの冗長構成とバックアップ・リカバリ

RAIDとかミラーリングの話。
アプリエンジニアという立つ場だと、正直知識としての優先度は下がるが、知っておいて損はないなと思った。

というのも、実際に障害が発生した際に、インフラ層の人が原因調査や復旧を頑張るところだが、知識として持っていると何故こういう障害が発生したのか、だったりうちのシステムはこういう冗長構成をとっているから障害に強いとかっていう話が理解できる可能性が上がる
あと、少しでも単語が分かると単純に面白い。

本書では、ER図の書き方や正規化の方法なども丁寧に触れていたが、普段DBを構築することのないアプリエンジニアの立場からすると、運用前の設計の知識よりもここら辺の運用後の話をインプットしておいた方が、前述の理由で触れる機会は多いのではないかと思う。

余談だが、応用情報受けようと思うと必ず通る道なのでこれからの人はちゃんと理解しましょう。

論理設計とパフォーマンス

この章に限らず本書で一貫してパフォーマンス面で繰り返していたのは、とにかくテーブル結合はコストが重いという話でした。
正直アプリにそのまま知識を流用するのは難しいですが、この知識を得られただけでも視野が広がる意味では学びは大きいかと思いました。

高次の正規化を行うとどうしてもテーブル同士が疎になっていくので、SQLで集計を行う際は結合が必要になってきます。
パフォーマンスと設計の美しさのトレードオフを取ることは、アプリエンジニアとしてもパフォーマンスの部分をソース運用とかに置き換えると身近に感じられるのではないでしょうか。

DB設計のバッドノウハウ

いわゆるアンチパターンをまとめた章です。
内容はもちろんですが、ここの章は学習本としては非常に有用でした。
というのも、これは絶対にやってはいけないを学ぶと、正しい手法への理解も深まるからです。
今後、別の分野の本を読む際にも目次にこういった項目が含まれるものは参考になる確率が高そうです。

さて、内容についてですが、一つのカラムに複数の意味を持つデータを投入するダブルミーニングや1つのカラムに配列をそのままぶち込む非スカラ値など、見た瞬間にこれはありえないよな。。。？といったものから、あらゆるマスターテーブルを一つのテーブルで管理する単一参照テーブル(個人的にはこれも直感的に結構あり得ない)、水平分割や垂直分割など一見よさそうにみえがちな設計まで幅広く取り上げていました。

こういったバッドノウハウを眺めていると自社の技術レベルなんかも見えて面白いですね。
(世の中にこんなはちゃめちゃなテーブルが実在すると思うと恐ろしすぎる。)

まとめ

ここまで達人に学ぶDB設計を読んでまとめてみました。
DB初心者から中級者に上がるための最適本といったレビューの通り、RDBについて非常に有益な情報をインプットできたと思います。
特にこういった内容でもアプリ開発に少しでも応用できないかという視点で読んでみると気づきも多く面白かったですね。

気になった方は是非手にとって読んでみてください！(ステマじゃなry)