database - 請求書データベースの設計

Question

数日前に、請求を処理するアプリケーションを作成しました。請求書に割引を最適に統合する方法を知りたいのですが。（invoice_itemsテーブルに）ネガティブアイテムとして配置する必要がありますか、それとも請求書テーブルに「割引」列を作成する必要がありますか？

Answer 1

私はそれを負の価値のあるアイテムとして持っているでしょう。理由は次のとおりです。

• 請求では、計算された値が永久に一定であることが非常に重要です。後で計算式が変更された場合でも、特定の請求書を正しく再現できます。これは、その時点で値が誤って計算されていた場合でも当てはまります。
• 価値のある金額があるということは、例外的な状況での手動調整が簡単に処理できることを意味します。たとえば、マーケティングマネージャー/会計士は、配達が遅れたために1回限りの100ドルの割引を与えることを決定する場合があります。これは負の値では些細なことです-別の行を追加するだけですが、割引率では難しい/面倒です
• 請求書ごとに複数の割引額を設定できます
• それは完全に柔軟性があります-それは存在し、それが必要なものであるための独自のスペースを持っています。実際、私は割引を別の「製品」にします（おそらく、複数の製品でさえ、クリスマス、クーポン、紹介など、明確な割引理由ごとに1つです。
• 独自のアイテムを使用すると、他の「商品」と同じように理由の説明を追加できます。たとえば、「現金払いの10％割引」などです。
• 特別なコードやデータベース列は必要ありません！以前と同じようにアイテムを合計して、請求書に印刷します。「スプーンはありません（割引）」：これは単なる別の項目です。コード/DBの変更が不要な場合よりも簡単なことは何でしょうか。
• すべてのアイテムを割引する必要はありません。たとえば、払い戻し、返品、サブスクリプション（該当する場合）。複雑になりすぎて、データベースで割引のビジネスロジックを表す必要がなくなります。計算などはアプリコードに残し、結果をデータベースに保存します
• 独自の項目があるということは、計算が任意に複雑になる可能性があることを意味します。これは、複雑さが増してもデータベースのメンテナンスが不要であることを意味します。データベースを維持/変更するよりも、コードを維持/変更する方がはるかに簡単です。
• 最後に、請求システムの構築に成功し、「アイテム」アプローチを採用しました。これは非常にうまく機能しました。

Answer 2

これらの選択のいずれかが将来あなたにどのような結果をもたらすでしょうか？たとえば、後で複数の割引、または非常に指定された割引を希望しますか？請求書ごとに割引が1つしかない場合は、必要以上に複雑にすることはありません。私の意見では、請求書の表に入れる方が簡単で明確です。ネガティブなアイテムとして持つと、アイテムの処理が難しくなると思います。

Answer 3

できるだけシンプルにすることに完全に同意しますが、考慮すべきことの1つは、割引を免除する必要があるアイテムがあるかどうかです。その場合、どの行に割引が必要かを覚えておくために、詳細にブールフィールドを追加する必要があります。