このトピックを検索しましたが、収集すべき説明がたくさんあります。ほとんどの場合、a/p と a/r で別々のテーブルを作成します。
a/c と a/r は 98% 類似しており、1 つまたは 2 つの属性だけが異なるため (たとえば、a/p: ベンダー/サプライヤー)、2 つのテーブルを 1 つに結合する別のアプローチを考えています。
質問：
2 つのテーブルをマージして、各トランザクションをまたはTransaction_Typeの値で分類することはできますAcnt_Payableかacnt_Receivable?
これが可能であることは知っていますが、これは良い習慣ですか？そして、私のシステムが対処するときに直面する状況は何Reportsですか?
あなたの質問は、「別のテーブルまたは別の列」です。type多くの MySql と会計データベースの操作を行ってきたことを考えると、追加のコラムとして持つことを躊躇しません。
レポートに関しては、レポートを取得するコードを作り直す必要があるということです。追加の列があるということは、結合が少なくなることを意味します (現在それらがある場合)。エラー チェックを強化する必要があります。既に設計されたソフトウェアに変更を加えると、ロジックの突然のパラダイム シフトである設計のニュアンスを以前は考慮していなかった場所で、常に不意を突かれるように思われるからです。
空白のキャンバスからレポート コードを書き直してください。「前回」からの経験の増加と、今回の新鮮な見方との間で、はるかに良い仕事をすることができます.
私見ですが、パフォーマンスの面では、ほとんどの企業とほとんどの平均的なコーダーは、MySql または PostgreSQL の既製のインストールで問題ありません。クエリに 1 秒以上かかる場合は、通常、インデックスを追加する必要があるためです。それを考えると、AR 対 AP (またはその他の人間の用語) を表す ID を持つさらに別のテーブルを作成できます。数字はパフォーマンスを高速化すると思います。
企業がパフォーマンスが本当に問題になるところまで来たら、本物の MySql 担当者を雇って介入させるリソースを手に入れることができます。皮肉:もちろん、quickbooks を使用している場合を除きます。その場合、1 日あたりのトランザクション数が 20 を超えると、ソフトウェアに過度の負担がかかります。