僕はこれまでPerl,C,C++,C#,PHP,Java,Ruby,Pythonといった感じで様々なプログラミング言語に触れてきました。プログラマーあるあるなのかもしれませんが、プログラミング言語は色々学ぶくせに、MySQLを深堀したりPostgreSQLとの違いを学んだりっていう事がおろそかになりがち。
WEBアプリケーションの運用を始めてから特に感じることは、データベースの重要度の高さです。「アプリケーションよりもデータベースの方が寿命が長い」という言い方をされたりしますが、ホントそうです。データベースに蓄積されたデータはそのまま資産にもなっていきますから。
仮に全然別のプログラミング言語で作られたアプリケーションへ移行しても、データだけは多少の整形をしつつ、そのまま移行させますからね。WEBアプリケーションの運用が始まって1年を過ぎ、機能の追加などを経て今も動いています。不具合というほどではないものの、設計を見直した方がいいんじゃないかという部分が鼻に付くようになってきました。リファクタリングでいうところの「Bad Smells in Code」みたいなものです。
データベース構造も今よりベターな形があるはず。そんなベターな形を見つけるべく本書を手に取りました。
この本を読んで特に役立った３つのポイントについてそれぞれまとめます。
金銭に関わる処理の履歴をどのように残しておき、ユーザーにどう表示すべきか？のヒントが得られた
予約システムにPOS機能を追加する際に、修正履歴をどうするか？というので随分悩みました。金銭のやりとりを含む処理になるので、間違いがあった際に正確に追跡できる必要があるからです。初めに打ったデータをUPDATEで上書き更新してしまっては元も子もないですから。
金融系のシステムを参考に、修正前にマイナス伝票を入れるという処理で実装・運用しているのですが、本書に事例のあった「取引履歴を別テーブルに記録していく」というアプローチもアリだと思いました。新しくブランチを切って試し、現行システムにとってどちらのアプローチが最適なのか検討してみます。
複数の目的に使われるカラムが存在することの悪影響を把握できた
機能追加の際に、「メニューテーブルの特定のIDのみ処理を分岐する」という処理をハードコーディングしている箇所があります。事業の根幹に関わる部分だったため、ソッコーで対応しなければいけなかったから、そうしました。で、期待する動きを実現してはいるものの、汎用性の低さが気持ち悪い。その気持ち悪さの原因をズバリ言い当ててくれるアンチパターンが紹介されていました。
「隠された状態」というやつです。「メニューIDが4の場合だけ別処理」というのはコードを見ないと知りようがないですし、同じシステムを動かしてる別の店舗では該当メニューIDが違うので、ハードコードしてる部分を修正→gitで管理してるソースコードが複数になってしまう。というドツボ状態に、いとも簡単にハマり込めます。
状態を保存するテーブルとメニューIDと状態IDの交差テーブルを作り、状態IDで条件分岐処理させる、が正解です。リファクタリング待ちリストに入れておきます。
トランザクション分離レベルという設定項目の存在を知れた
そもそもの知識不足だったんですが、トランザクション分離レベルというものが存在することを初めて知りました。しかもMySQLとPostgreSQLでデフォルトの挙動が違う！
並列処理を走らせる中でデータの一貫性を担保するために、どこで適切にロックをかければいいのか？といったことを考える際にトランザクション分離レベルについても知っておく必要が出てきます。
まずは、トランザクション分離レベルの違いを手を動かして体感してみます。
失敗から学ぶRDBの正しい歩き方
WEBアプリケーションの運用を始めてデータが蓄積してくると、「このデータベース構造、将来的に破綻しないか？」といった疑問が浮かんできたりします。この本のアンチパターンを知っておくことで、改善のヒントが得られるかもしれません。良書です。
単行本（ソフトカバー）: 288ページ
出版社: 技術評論社 (2019/3/6)
言語: 日本語
ISBN-10: 4297104083
ISBN-13: 978-4297104085
発売日： 2019/3/6
コメント