複式家計簿③　データベーススキーマ

本日は、複式家計簿アプリ DIY シリーズの第三弾です。

• 初回：複式家計簿①　我が家の家計簿アプリ
• 前回：複式家計簿②　日々の仕訳

今回は、DIYした家計簿アプリのデータベーススキーマをご紹介します。

前提として、データベースは Cloudflare D1 ↗ を採用しています。

ER図

筆者は KISS 原則原理主義者なので、極限までシンプルさを追求しました。

設けたテーブルは3つだけ。

• journal_entries
• journal_entry_lines
• balance_forwards

仕訳と仕訳行

複数明細を持つ仕訳を表現するには、以下のような情報が必要です。

• 仕訳メタデータ
  • 日付
  • 摘要（= 取引のサマリー）
• 仕訳行
  • 勘定科目
  • 金額
  • 借方か貸方か

これらの情報を第三正規形に則って整理したのが journal_entries と journal_entry_lines です。

開始残高

所得税の期間が 1/1 〜 12/31 であることに合わせ、帳簿のライフサイクルも同様の期間で完結するようにしました。

そして、資産・負債・純資産の勘定科目については、年末帳簿を締め切るタイミングで残高を翌年に持ち越す必要があります。 これを表現するのが balance_forwards テーブル、すなわち 「開始残高」 です。

このテーブルの存在意義は、「計算範囲を当該年度のみに限定できる」 ことです。

我が家の家計簿の場合、1月あたりの仕訳数は多くても100を超えません。開始残高を取得 → その年度の仕訳を全て取得 → 集計、とすることで 高速・リアルタイム・シンプルなコード、三拍子揃った財務諸表を実現できました。

勘定科目は？

ハードコーディングです

• 勘定科目の種類を増やすのは、月に1回あるかないか
• 勘定科目に関わる整合性をデータベースレイヤで保証する必然性はない

この2点を踏まえて、あえてデータベースの世界から追い出しました。新しい勘定科目が必要になったらコードを編集してデプロイします。

まとめ

我が家の家計簿アプリのデータベーススキーマを紹介しました。

個人用途の趣味アプリだと、ちょっと極端なミニマリズム追求ができるのがとても楽しいです。