財務記録を保持するデータベースを設計する場合、どのような特別な考慮が必要ですか？
この質問が広すぎないことを願っています。将来的には、一部のアプリケーション（主にWebベースのアプリケーションですが、私の質問はデスクトップアプリにも当てはまります）にいくつかの会計システムと財務追跡システムを追加する必要があるかもしれません。
現在、金融取引の単純な記録を作成することは理論的には簡単です。いくつかの列を持つ1つのデータベーステーブルがその仕事を果たします。 MS Access、Excel、または単なるASCIIテキストファイルでも、トランザクションの日付、アカウントID、ドルの金額を保存するために使用できます。しかし、頻繁にバックアップされるSQLトランザクションの整合性を持つテーブルは、深刻な財務追跡を行うには十分に堅牢ではない可能性があります。
「複式簿記」のような言葉を聞き、ほとんどの財務追跡アプリ（たとえば、Mint.comやGnuCash）は、すべてのことを二重に保証するために、はるかに複雑なデータ構造またはプロセスを備えていると感じます完全に正確に加算され、データが失われたり破損したりすることはありません。
私の質問は： 金融取引を追跡するためのアプリを設計するとき、どのような特別な設計上の考慮事項を行う必要がありますか？ 非常に多くの潜在的な問題があるように思われます...丸めの精度、パリティチェック、ある種の監査プロセス、特別なバックアップ、セキュリティ/暗号化、データエントリの途中でクラッシュした場合にデータを保護する追加の方法に関する問題。 ...私が具体的に何を尋ねるべきかは本当にわかりませんが、プログラミング業界には私が何も知らない一連のベストプラクティスがあると感じています。彼らは何ですか？
編集：
予想以上に大きなワームの缶を開けたようです。明確にするために、私は特に2種類のアプリについて考えています。
- 「チェックレジストリ」タイプのアプリ。GnuCashやQuickenのように、個人でのトランザクションの記録を自分で使用するために保持します。
- 会社と取引するベンダーや顧客の請求/クレジット/「ポイント」を追跡するアプリ。
私はおそらく、ダイレクトバンキングや（AFAIK）に関連する大量の金融関連の政府規制があるものは何もしません。
あなたは私が確信しているこれに対する多くの答えを得るでしょう、多くの理想主義的な答えもそうです、私は財政の経験と実際に何が起こっているかからのみ答えることができます。
あなたはすでに問題の大部分をカバーしました。
丸めの精度は、実際には私の経験ではそれほど問題になりません。一晩で成長していない大規模な金融機関の大多数（つまり、ヘッジファンドを除くすべて）には、さまざまな燃料のために分割されたレガシーアプリケーションが数多くあります。彼らは一貫して丸め精度を行わない傾向があります。一般的に、特定のエラーの利益と損失は単純に丸められます。実際、私が働いた場所で多くの人時間が費やされています。人間が、正確な/期待値の合計を一致させることに関して、究極的には「十分に近い」セレクターがある場所で費やされています。覚えておいてください、これは現実に基づいた答えであり、何が起こるべきかではありません。
暗号化-率直にそれに依存しないでください。識別データを、匿名化されたデータとは物理的および論理的に別のシステムに格納します（つまり、アカウントコードをどこにでも、個人データを分離します）。
通常、バックアップが必要な場合、オフラインバックアップが呼び出されることはめったにありません-その時点で事態はひどく間違っています。暖かい本番コピーが一般的に必要ですが、これはあなた自身の特定のニーズに依存します。一般的に、すべてのシステムのウォームオンサイト本番コピーと、独自の本番およびウォームコピーを備えた災害復旧サイトがあります。ウォームコピーは、レプリケーションなどで数分遅れる傾向があります。
監査は、これまで取り組んできたすべての金融システムの鍵です。 2つの基本的な要件があります。A）データに加えられたすべての変更を、誰が、いつ、なぜ行ったかを追跡できますか？ B）データの履歴状態を証明できますか？改ざんされていないということですか？
A）運用チームには必須–システムは予想外の100の方法で使用されるため、この情報は拡張、アドホックレポート、法的理由、デバッグに不可欠です。
B）AMEX対Vee Vinhneeのケースを参照してください。AMEXは、レコードが作成されていないことを証明できなかったため、彼らに支払われた40kを収集できませんでした。これに一般的に使用されるソリューションは、信頼できるタイムスタンプです。大規模な金融機関には、取引を保証する保証銀行があり、本質的に信頼できるタイムスタンプを提供します。他の人生の歩み/シナリオのために、このための商用プロバイダーがあります。
考慮事項はほとんどが合法的なものです。安全性/信頼性の観点から見た場合、Excelシートは一部の引き出しにある紙のシートよりも本質的に安全ではない可能性があります。 Accessのトランザクションの整合性は、コールによって中断される店員よりも優れている場合があります。
しかし、あなたの顧客がそれを使用することを許可されるためには、あなたはあなたの地域の法律に従って作る必要があります。私が遭遇したいくつかのこと（ドイツ語）
- 企業が10年間書類を保管しなければならないという法律があるため、ストレージに関するドキュメント形式。 10年後には、プログラムが利用できなくなる可能性があります。したがって、ドキュメントはDIN/ISO認定の方法で保存する必要があります（ドイツ語では.pdfで十分のようです）。
- 多くの場合、監査証跡が必要です。同じドキュメントの異なるバージョンを変更日とともに提示しなければならない場合があります。
- 保管場所は重要です。 'Datenschutz'（プライバシー）のため、保管国によって異なる場合があります。このため、クラウドベースのサービスは少しトリッキーになります。
- 一部のドキュメントは、変更できない方法で保存する必要があります。これがどのように正確に達成されるかは、主に法的根拠に依存するようです（紙は不変であり、CDは変更可能ですが、労働者が署名したCDは変更できません）
具体的には、弁護士に明確に連絡するか、少なくとも顧客と緊密に連携する必要があります。
人々のお金を扱う場合、信頼性の要素は驚くほど重要になります。 Twitterがツイートを失ったとしても、それほど大きな問題ではありません。誰かのクレジットカードに請求したが注文を失った場合、組織内の誰かが怒っている顧客から耳を傾けることになります。つまり、2つのことです。1。それが最初に起きるのは望ましくありませんが、2。どれだけ注意しても最終的には起きるので、ロギングとトレースのメカニズムの種類にたくさんのエネルギーを入れたいと思います。これは、戻って「失われた」注文を見つけて状況を修正するのに役立ちます。
絶対に最悪のことは、例えばクレジットカードの請求をすることですが、それが何のためにあるのか、それが誰に属しているのかなどの記録はありません。
金融関連の場合は、一見すると非常にありそうにないシナリオでさえ考え、それらの処理方法を計画する必要があります。「クレジットカードに請求しましたが、対応するレコードを更新する前にデータベースサーバーがダウンしています。」さて、何ですか？ Void料金？トランザクションをファイルに記録して、後で修正できるようにしますか？ディスクがいっぱいでファイルに書き込めない場合はどうでしょうか？など.
[1]ユーザーとアプリにセキュリティテーブルを使用します（内部D.B.ユーザーと混同しないでください）。モジュール、フォーム、ウェブページ：
User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}
[2]アプリ内のレコードを削除しないでください。レコードが「削除済み」と見なされることを示す、ステータスフィールド（整数、ブール値、またはビット）を使用してください。アプリを作成します。削除されていない（そのフィールドによって削除済みとしてマークされている）レコードを表示し、アプリがどこにあるのか、いくつかの特殊なケースのフォームを作成します。削除済みとしてマークされたレコードは表示されません。
anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }
この機能は「仮想削除」と呼ばれます。実際の削除は、しばしば「物理的な削除」と呼ばれます。
[3]アクセスに関連するすべてのテーブルのフィールドを使用し、レコードを作成した（単一の）ユーザー、レコードを変更した（最後の）ユーザー、および日時（可能な場合）、各レコードがあったモジュールまたはオプションを追加します変更：
AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }
[4]場合によっては、通貨または金額の値が複数のレコードを詳細に使用し、ヘッダーレコードの1つの値に追加すると、結果に影響を与えることがあります。
ほとんどのデータベースブランドは、現在、通貨または通貨のデータフィールドをサポートしています。これを使って。
一部の特別な状況では、一部の人々は、それらをいくつかの10進数（「10進数」）をサポートする固定の浮動小数点値に、または文字列値としても格納します。
これらの技術は、両刃の剣です。アプリケーションがそのようなプレシジョンを必要とする場合は、適切に実装する方法に関するチュートリアルをWebで検索してください。
乾杯。 [キティにオープンなツナ缶を与えるか、少なくとも賛成投票をすることを忘れないでください]
私が見ている考慮事項のいくつかは、内部統制を説明しなければならないということです。つまり、テーブルに対するアクションへのすべてのアクセス（挿入/削除/更新）は、ストアドプロシージャ（および動的SQlではない）を介して行われる必要があるため、システム管理者以外の誰に対しても、テーブルに対する直接の書き込みまたは削除権限を許可するテーブルはありません。また、誰かが新しい会社を作成し、その会社にアイテムを請求することを許可しない内部統制についても考慮する必要があります（詐欺のルート）。そのようなアクションでは、常に2つの異なる役割の人々が承認する必要があります。また、1人の人がデータを入力し、別の人が費用を承認しない限り、小切手は切られません。
すべてのテーブルには、監査レコードを作成するトリガーが必要です。あなたは詐欺を防ぎ、それが偶然誰がいつ行動を起こしたかを正確に決定することを望んでいます。
金融アプリケーションでは、ユーザーインターフェースでは決して表示されない多くのバックエンドプロセスに関心があります。あなたの最初の懸念は詐欺を防ぐことであり、そのためバックエンドでは誰にも気付かれない多くのチェックが行われます。
GAAPを十分に理解せず（米国では他の国にも独自の会計基準があります）、誤った会計慣行が刑務所につながる可能性があるため、コンサルタントとしてCPAを持たない限り、私はいかなる種類の金融アプリケーションにも取り組みません。これは非常に技術的な分野であり、必要な知識がない人はこの分野でソフトウェアを作成しようとすることはありません。
質問にsecurityのタグを付けましたが、あなたはほとんど一貫性と信頼性について話しているので、方程式のその部分に答えようとします：
- データベーストランザクションを使用して、バッチ操作の整合性を確保します。最も基本的な例は、2つの口座間の振替です。一方の口座から金額が差し引かれ、もう一方の口座に入金されます。トランザクションを使用して、部分的な転送が発生しないようにします（片側のみが変更されます）。
- 精度を上げるには、floatの代わりに
DECIMAL型を使用します。計算ははるかに遅くなりますが、ほとんどの財務計算は非常に基本的なため、それを感じる必要はありません - アップタイムにはレプリケーションを使用し、バックアップにはホットコピーを使用します。また、回復のために LVMスナップショット を調べる必要があります。
会計はしばしば検証に関するものです。これを覚えていて、各エンティティ間の関係を理解している限り、間違いを犯すのはかなり困難です。
私はできる限り多くのチェックをリストアップしようとしますが、常にいくつかのチェックを逃します。うまくいけば、あなたがあなた自身の掘削を始めるのに十分であることでしょう。
合計借方==合計貸方。これは、アカウントの全体のセットについて話しているのか、単独で1つのトランザクションについて話しているのかに関係なく当てはまります。集計されない場合は、どこかで少なくとも1つの投稿を見逃しています。これが総勘定元帳のバランスです。
売掛金（管理アカウントへの正味借方）==請求額の合計（すべての請求額の合計）-受け取った合計（受け取ったすべての支払いの合計）。これは、実際の物理的および有形の文書条件でのトランザクション合計が総勘定元帳とどのようにバランスするかを示す例です（二重入力）。
銀行残高（銀行の明細書による）==そのアカウントの総勘定元帳の合計+入金されなかった小切手-預金されていない発行された小切手。これは、銀行/現金勘定が総勘定元とどのように集計されるかの例です元帳。
ご覧のように、すべてのトランザクション、サブ元帳、さらには株式も総勘定元帳に直接関連付けられています。
単体テストを実行している場合、何をチェックするかを理解している限り、トランザクションを挿入/更新するたびにこれらのバランスが存在することを確認するテストを実行するのは非常に簡単です。
もちろん、チェック/集計するバランスが他にもありますが、必要な作業の要点を取得する必要があります。基本的に、物理的な文書、総勘定元帳の項目、銀行取引明細書など、すべてが他のすべてとバランスをとっています。それは完璧なバランスであるか、または丸めに対処するのが面倒な場合は、完璧に近いと思われます。
開発中に実行できるチェックの数が多いほど、問題が発生する可能性が低くなります。
ところで、丸めを処理するときは、浮動小数点数ではなく小数を使ってみてください。これにより、将来の頭痛の種を大幅に減らすことができます。 ：P