家計簿管理サイトkakerubo

主な使用技術：PHP MySQL HTML CSS

目次：

|   制作のきっかけ  |   苦労したこと  |   試行錯誤  |   工夫  |   完成品について  |   今後について  |

Reason制作のきっかけ

私は現在一人暮らしをしており、金銭面をすべて一人でやりくりしています。そのため、収入と支出をはっきりさせ、節約できるところを探したり、最近使いすぎている部分を見つけたりするために家計簿をつけていました。
しかし、出先だとExcelに打ち込めるようなものは持ち歩いていませんし、かといってある程度溜めると家計簿につけるのも億劫になっていました。そこで、使ったときにさっとつけられて、かつシステム側でジャンル分けして、グラフのように視覚化してくれるような、家計簿アプリがあったらいいなと思ったのがきっかけです。

Difficulty苦労したこと

この開発で苦労したのは、なによりもDBの設計です。普段からバックエンドでDBに関わっている方であれば「この程度で何が苦労だ」と思われるかもしれませんが、実はしっかりとDBをユーザ毎に作るようなシステムを考えたのは、この開発が初になります。Javaの開発の時は複数ユーザが使用することを想定していなかったということもあり、DBの構造設計についてはそこまで大きくこだわりませんでした。
しかし、今回はユーザがサインアップをして使用することを想定したため、ユーザ数が増えた時にレスポンスが遅くならないようにするためにはどうするべきかなどを考えて設計しました。DBの正規化を含め、小さなシステムとはいえ、初めての経験なりに苦労した記憶があります。

Trial and Error試行錯誤

試行錯誤した点として、ユーザ数が増えた時のレスポンスの最適化、データの可視化(グラフの利用)の2点があります。
1点目のレスポンス最適化については、苦労したことでも述べた通り、ユーザ毎にDBを作成するという手法を取りました。これによって、ログインした時点で使用するDBを決定し、それをCookieやSessionで管理することが可能になり、他のユーザのデータに依存しないレスポンス速度を実現することができました。これは検索処理が簡易化されたことによるもので、数万人が登録しても、一人当たりのレスポンスは変わらないようにすることが可能になりました。
2点目のデータ可視化についてはVue.jsのgoogle chartsを活用することで、視覚的に、なんとなくどういう傾向があるのかを直感的に理解できるよう工夫しました。元々はテーブルのみで表示する予定でしたが、家計簿をつけることで全体及び最近の傾向を把握するためには、この手法が優れているだろうと考えて採用しました。

Ideas工夫

何度か記述してしまっているので重複はしてしまいますが、ユーザ毎にDBを作成することで、どれだけユーザが増えてもシステム内のCRUD処理に影響が及ばないように工夫しました。逆に言えば、DBサーバがそれだけ必要になってしまうので、クラウドを利用するとすれば、それだけの費用が掛かることが想定されます。このシステムはデータ同士の関連性が大きく、NoSQLにするというよりはRDBの方が向いていると考えているので、その部分の高速化が別の方法で置き換えられないか、今後学習していこうかなと考えています。
このDBの構造設計をきっかけに、他のシステムでDBを活用する際、しっかりと大規模トラフィックになった際のボトルネックがどこに生まれるかというのを考えるようになりました。これは良い学習の機会となったと思っていますし、今後も必要となる知識、技術であると思っております。

Finished完成品について

このシステムはローカル上で動作するものになるので、実際にお使いいただくことはできません。DBの構造についてはGitHubにアップロードしてありますので、ぜひご確認ください。

Future今後について

今後は、firebaseやAWSといったクラウド技術を利用して、ホスティングサービスでウェブサイトを公開しようかと考えております。また公開した際には、TOPのお知らせに掲載いたします。