複式簿記スキーマ
個人で使用するための、および非常に小規模なビジネスの管理を支援するための複式簿記システムのセットアップ。現在関連があると思われるいくつかの機能を配置しようとしています。
ビジネスルール
会計に詳しくない人にとっての論理は、お金は作成も破壊もされず、口座から別の口座に送金されるだけです。各トランザクションには、借方側と貸方側があります。いくつかの例：
雇用主からの給与：クレジット
Salary、借方Bank Account-お金はあなたの給料から来て、あなたの銀行口座に行きました。家賃の支払い：クレジット
Bank Account、デビットRent-銀行口座から入金され、家賃口座に入金されました。
アカウントは、残高が累積的である（銀行口座が良い例です）意味で「ストック」アカウントであるか、またはアカウントの残高が非累積的であるという意味で流動/フローアカウントであることができます（家賃は良い例です）。
デザインの背後にあるロジック
アイデアは、主要なエントリを格納する主要なJournalDBテーブルを用意することです。テーブルJournalTxには、トランザクションに関連する各アカウントが格納されます。各エントリ（JournalDBから）にはIDがあり、各トランザクション（JournalTxから）はジャーナルエントリにリンクされています。基本的なケースのシナリオでは、JournalDBに1つのエントリがあり、JournalTxに2つ（またはそれ以上）のトランザクションがあります。各エントリにはcost_center、project、およびその他のいくつかの属性。
それを設計する方法は基本的に2つあります（ この質問に従って ）-トランザクションスタイルごとに1行、トランザクションごとに2行。最初の例では、クレジットアカウントとデビットアカウントの行が1つあります。2つ目（この行）には、影響を受ける各アカウントに1つずつ、n行があります。
アカウント
勘定科目表は、（会計士の専門用語での）勘定科目表です。階層構造です-隣接リストスタイルを使用しました。それほど頻繁ではありませんが、アカウントにはCRUD操作があります。追加した parent_imediate、parent_second集計を行うための本当に醜い解決策（たとえば、資産アカウントの合計を計算する）ですが、課題（長い調査の後でそれをどのように行うかわからない）を考えると、簡単な方法のように見えましたその件に関する意見や提案も歓迎します。
主なクエリ
レポートを取得します。通常はmontlhyです。基本的に、すべてのトランザクションは、そのそれぞれに影響を与えた集計トランザクションと見なされます。最良のシナリオは、ピボットテーブル（日付としての列）で、各行がアカウントです。これの "スタック"バージョンも問題なく動作すると思います。
アカウントは1つのディメンションにすぎません-cost_centerまたはprojectなど。
その他の特徴
私はアカウント（つまり、予算表）を予算化する機能と、「目標」（私が1.000ドルの費用がかかる休暇を取ること）を持ちたいと考えています。また、タグを付けて、定期的な請求書（「予想される」トランザクション）を設定できるようにしたい
基本的な関係
1つのエントリ（journal_db）には多くのトランザクション（journal_tx）があります。 1つのcost_center、projectなどには多くのエントリがあります1つのアカウントには多くのトランザクションがあります。 1つの連絡先に多くのエントリがあります。
私の主な疑問
私はDB /プログラミングについて学び始めたばかりなので、明らかな間違いについては我慢してください。
- このデザインは、プログラミング/パフォーマンス/機能の観点からはしっかりしていますか？
- レポートを実装する方法は？ DB（派生テーブル）にクエリを実行するか、新しいテーブル（journal_reportsなど）を作成し、各エントリの口座残高を更新するトリガーを作成しますか？ （ この質問 を読んでください、それはそれほど素晴らしいアイデアではありません）
- 不足している可能性があるものはありますか？
あなたの質問はかなり広範で、全体として答えるのは難しいと思います。しかし、ここに私があなたのデザインについて気づいたいくつかのことがあります：
一般的なデザイン
デザインの一部のテーブルは、最初の正規形に違反しています。良い例は、contact_adress、adress1、adress2を列として持つadress3です。通常、場所には1つの住所しかなく、1つの住所列で十分ですが、複数の住所を1つの場所に追加する機能が本当に必要な場合は、それらの住所を別のテーブル（contact_adress、street_adress）に移動する必要があります。 journal_bills（detail1、detail2）とaccountsテーブルについても同じことが言えます。parent_imediate、parent_second、parent_thirdの代わりに、単一のparent属性で十分です。 2番目または3番目の親を取得するには、代わりに recursive CTEs を使用できます。
私はあなたのビジネス要件のすべてを知りませんが、あなたの設計が無意味なデータを入力することを可能にするかどうかを確認する必要があります：アカウントは現金とクレジットの両方にすることができますか？あなたが通貨を持っているなら、為替レートは何ですか？郵便番号は1つ以上のゼロで開始できますか？電話番号はどうですか？いくつかのものについては、ベストプラクティスがあります。 繰り返し発生するイベントへの対処方法 。
ネーミング
一部の列名（ag、acc、pmt）は理解しにくいため、他の誰かがデータベースを操作する必要がある場合、保守性の問題につながる可能性があります。名前の付け方がわからない場合は スタイルガイド を使用してください。一般に、一貫した命名方式を使用することをお勧めします。すべてのテーブルに複数の名前を付けます。
レポートを実装する方法は？
私は単純なSQLクエリに固執し、本当に必要な場合を除いて、トリガーなどの高度な関数を避けようとします。これは、単純なアプリケーションの場合にはおそらく当てはまりません。