これらは3つのSQLテーブルか1つですか？

StackOverflow https://stackoverflow.com/questions/1414611

質問

これは、この質問

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

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

  • トランザクションは相互信用のようにユーザー間で行われます。したがって、ユニットはユーザー間で交換されます。
  • インベントリ化は、システムに持ち込まれる物理的なものです。ユーザーはこのためのユニットを取得します。
  • 消費は消費される物理的なものです。ユーザーはこのために単位を支払う必要があります。
|--------------------------------------------------------------------------|
|  type     |  transactions       |  inventarizations  |  consumations     |
|--------------------------------------------------------------------------|
|  columns  |  date               |  date              |  date             |
|           |  creditor(FK user)  |  creditor(FK user) |                   |
|           |  debitor(FK user)   |                    |  debitor(FK user) |
|           |  service(FK service)|                    |                   |
|           |                     |  asset(FK asset)   |  asset(FK asset)  |
|           |  amount             |  amount            |  amount           |
|           |                     |                    |  price            |
|--------------------------------------------------------------------------|

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

問題は、「これを1つのテーブルに入れるか、複数のテーブルに入れるか（今のところ持っていますか？）」意味的にもっと意味があるので、私は3つのテーブルのソリューションが好きです。しかし、その後、running_balancesに対して、このような複雑なselectステートメント（パフォーマンスが低下する可能性がある）が必要です。上記のリンクの元の質問はこの声明を求めていましたが、ここではdbの設計が適切かどうかを尋ねています（4つの二重投稿を謝罪し、大丈夫だと思います）。

役に立ちましたか？

解決

これと同じ質問は、単一エントリの簿記用に総勘定元帳システムを実装しようとするときに発生します。あなたが「トランザクション」と呼んだもの貯蓄からチェックまで、「振替」に対応します。あなたが「発明」と呼んだもの給与の入金など、「収入」に相当します。あなたが「消費」と呼んだもの電気料金を支払うときなど、「費用」に相当します。唯一の違いは、簿記では、すべてがドル（または他の通貨）の値に削減されていることです。したがって、1ドルは別の1ドルと同じであるため、資産を識別することを心配する必要はありません。

「借方金額」に個別の列が必要かどうかという疑問が生じます。および「クレジット額」または、[金額]の列を1つだけにして、借方には正の数を、貸方には負の量を入力できるかどうかを指定します。単一エントリの簿記ではなく、二重エントリの簿記を実装している場合、本質的に同じ質問が発生します。

内部演算および内部データ処理の観点から、単一列アプローチを採用すると、状況ははるかに単純になります。たとえば、特定のトランザクションのバランスが取れているかどうかをテストするには、合計（金額）がゼロに等しいかどうかを確認する必要があります。

データ入力フォーム、画面上の検索、および公開されたレポートに従来のブックキーピング形式が必要な場合に問題が発生します。従来の形式では、「借方」とマークされた2つの列が必要です。 「クレジット」には正の数字または空白のみが含まれます。すべてのアイテムに借方または貸方のいずれか一方のエントリを含める必要があり、両方のエントリを含めることはできません。これらの変換では、外部形式と内部形式の間である程度のプログラミングが必要です。

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

あなたの場合、データをどのように使用するかによって異なります。 2つのデザインのそれぞれでプロトタイプを作成し、それぞれの基本的なCRUD処理の作業を開始します。お使いの環境で簡単に解決できる方を選択してください。

他のヒント

金額は異なる単位になるとおっしゃいましたが、各テーブルをそのままにしておくべきだと思います。

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

残高の質問に答えるインデックス付きビューを作成して、クエリを「シンプル」に保ちます

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

私のアドバイスは、両方の方法を試して、クエリ、パフォーマンス、メンテナンス/使いやすさのいずれが最良の妥協案であるかを確認することです。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top