財務記録を保持するデータベースを設計するとき、どのような特別な考慮事項が必要ですか？
この質問が広すぎないことを願っています。将来的には、いくつかのアプリケーション（主にWebベースのアプリケーションですが、私の質問はデスクトップアプリケーションにも関係します）にいくつかの会計および財務追跡システムを追加する必要があります。 現在、金融取引の簡単な記録を作成することは理論的には簡単です。いくつかの列を持つ1つのデータベーステーブルで作業を行うことができます。MS Access、Excel、または単なるASCIIテキストファイルでさえ、取引日、アカウントID、および金額を保存するために使用できます。ただし、トランザクションの整合性を備えた頻繁にバックアップされるSQLテーブルでさえ、深刻な財務追跡には十分な堅牢性がない場合があります。 「ダブルエントリアカウンティング」などの用語を耳にしますが、ほとんどの財務追跡アプリ（たとえば、Mint.com、GnuCash）には、すべてを確実に二重にするために、はるかに複雑なデータ構造またはプロセスが用意されているように感じます必要に応じて完全に加算され、データが失われたり破損したりすることはありません。 私の質問は次のとおりです。金融取引を追跡するアプリを設計するとき、特別な設計上の考慮事項を作成する必要がありますか？非常に多くの潜在的な問題があるようです...丸め精度、パリティチェック、ある種の監査プロセス、特別なバックアップ、セキュリティ/暗号化、データ入力中にクラッシュした場合のデータを保護する追加の方法に関する問題。 ...私が具体的に何を尋ねるべきかは本当にわかりませんが、プログラミング業界には私が何も知らない一連のベストプラクティスがあると感じています。彼らは何ですか？ 編集： 予想以上に大きなワームの缶を開けたようです。明確にするために、私は特に2種類のアプリについて考えています。 GnuCashやQuickenなどの「レジストリの確認」タイプのアプリは、個人が使用するトランザクションを記録します。 企業と取引するベンダーと顧客の請求書/クレジット/または「ポイント」を追跡するアプリ。 私は恐らく、ダイレクトバンキングや（関連する）多くの金融関連の政府規制が添付されているものは何もしないでしょう。