1

これは、この質問から生じた新しい質問です

回答により、質問の性質が変わったので、新しい質問を投稿しても問題ないと思います（？）。

以下に、私の元の DB デザインを示します。3 つのテーブルがあり、running_balances 計算のために特定のユーザーのすべてのレコードを取得するクエリが必要です。

  • トランザクションは、相互信用のようにユーザー間で行われます。したがって、ユニットはユーザー間で交換されます。
  • 発明化は、システムに持ち込まれる物理的なものです。ユーザーはこれに対して単位を取得します。
  • 消費は消費される物理的なものです。ユーザーはこれに対して単位を支払う必要があります。
|---------------------------------------------------------------- --------------------------|
| | タイプ | 取引 | 発明 | 消費 |
|---------------------------------------------------------------- --------------------------|
| | コラム | 日付 | 日付 | 日付 |
| | | | 債権者(FKユーザー) | 債権者(FKユーザー) | | |
| | | | 借主(FKユーザー) | | | 借主(FKユーザー) |
| | | | サービス（FKサービス）| | | | |
| | | | | | asset(FK アセット) | asset(FK アセット) |
| | | | 金額 | 金額 | 金額 |
| | | | | | | | 価格 |
|---------------------------------------------------------------- --------------------------|

（「金額」は異なる単位であることに注意してください。これらはエントリであり、それらの金額に対して計算が行われます。理由を説明する範囲外ですが、これらはフィールドです）。

問題は、「これを 1 つのテーブルにすることができるか、それとも複数のテーブルにする必要があるか (今のところ)」です。意味的により理にかなっているので、私は 3 つのテーブル ソリューションが好きです。しかし、running_balances には複雑な select ステートメントが必要です (パフォーマンスが低下する可能性があります)。上記のリンクの元の質問は、このステートメントを求めていました。ここで、データベースの設計が適切かどうかを尋ねています (4 つの二重投稿をお詫びします。問題ないことを願っています)。

4

3 に答える 3

2

単式簿記用の総勘定元帳システムを実装しようとすると、これと同じ疑問が生じます。あなたが「取引」と呼んだものは、貯蓄から小切手へのような「送金」に対応します。あなたが「発明」と呼んだものは、給料の預金のような「収入」に相当します。あなたが言う「消費」は、電気代などの「費用」に相当します。唯一の違いは、簿記では、すべてがドル (または他の通貨) の価値に還元されていることです。資産の特定について心配する必要はありません。

したがって、「借方金額」と「貸方金額」に別々の列が必要か、それとも「金額」に 1 つの列だけを使用して、借方に正の数値、貸方に負の数値を入力できるかという問題が生じます。単式簿記ではなく複式簿記を実装している場合、本質的に同じ問題が発生します。

内部演算と内部データ処理に関しては、単一列アプローチを採用すると、物事ははるかに単純になります。たとえば、特定のトランザクションが残高にあるかどうかをテストするには、合計 (金額) がゼロに等しいかどうかを尋ねるだけです。

データ入力フォーム、画面上の検索、および公開されたレポートに従来のブックキーピング形式が必要な場合、複雑さが生じます。従来の形式では、「借方」と「貸方」とマークされた 2 つの別個の列が必要です。これらの列には、正の数値または空白のみが含まれます。すべての項目に借方または貸方のいずれかのエントリが必要であり、両方ではなく、もう一方の列が空白のまま。これらの変換には、外部形式と内部形式の間である程度のプログラミングが必要です。

それは本当に選択の問題です。借方と貸方の列を並べる従来の簿記形式を維持する方がよいでしょうか、それとも意味のある方法で負の数を使用する形式に移行する方がよいでしょうか? これらの設計の選択のそれぞれに有利な状況がいくつかあります。

あなたの場合、データをどのように使用するかによって異なります。2 つの設計のそれぞれでプロトタイプを作成し、それぞれの基本的な CRUD 処理に取り組み始めました。あなたの環境でより簡単に機能する方を選択してください。

于 2009-09-12T12:54:56.993 に答える
2

金額は異なる単位になるとおっしゃいましたが、各テーブルを独自に保持する必要があると思います。

個人的には、行に格納されたエンティティのタイプに基づいてテーブルを埋めるための「異なるルール」を持つ DB 設計が嫌いです。ぐちゃぐちゃになるだけで、そのようなテーブルで制約を適切に維持するのは困難です。

クエリを「シンプル」に保つために、バランスの質問に答えるインデックス付きビューを作成するだけです

于 2009-09-12T08:31:12.633 に答える
0

これに対する決定的な答えはありません。答えは主に、回答者が採用したデータベース設計方法論に依存します。

私のアドバイスは、両方の方法を試して、クエリ、パフォーマンス、メンテナンス/使いやすさの間でどちらが最善の妥協点であるかを確認することです.

type3 つのテーブルすべてをクエリ用の 1 つのテーブルとして返し、行が関連するプロセスのタイプのフィールドを持つビューを常に設定できます。

于 2009-09-12T08:34:15.963 に答える