Mysqlで銀行口座のような出入金管理

PerlとMysqlでWebアプリケーションを構築しています。

その中で銀行口座のような入金・出金・残高・日付・摘要のような項目があります。
実際はお金ではなく、ポイントなので
入ポイント・出ポイント・残高ポイント・摘要です。
（日付・摘要はここでは問題ではありません）

そこで本題なのですが、こういったDBを設計する際にフィールドは
入ポイント・出ポイントの２つにして、残高は出力する際に計算するのがいいのか
それとも
入ポイント・出ポイント・残高ポイントの3つにして、インサートするさいに
毎回前残高を取得して、計算後インサートするのがいいのでしょうか？

※ちなみに会員用のシステムなのでその他にIDフィールドなどがあるのはここでは割愛しております。

不明な点や不足情報があればご指摘ください。

恐れ入りますがよろしくお願いいたします。

No.2 ベストアンサー 回答者： Unripe01 回答日時： 2012/08/16 22:30

＞ここでおっしゃっている源泉というのはどういった解釈をすればいいのでしょうか？

源泉は、そのデータが発生したそもそもの要因と考えていました。

＞ブラウザ上で表示したい内容は～～

失礼しました。
売上の履歴も含めて表示させたいってことですね。
てっきり、１ユーザー１レコードで、出ポイントと入ポイントは
それぞれ変動するたびに計算するデータ構造だと思い込んでました。
すみません。（Yahooや楽天の残ポイント表示みたいな感じ）

select （ sum( 入ポイント ) - sum( 出ポイント) ） AS　残ポイント
from ターゲットのテーブル
group by ユーザーID

こんなかんじで・・・

履歴をそのまま表示させるということでしたら、
残ポイントがあったほうがいいかもしれませんねぇ・・・

ちなみに、私が上記設計をすると断見してしまったのは
Yahooポイントの獲得情報を真似てのことでした。

Yahooの場合、
◆合計表示場所
-----------------------------------
利用可能ポイント：9999
-----------------------------------
◆履歴
-----------------------------------
取引日：9/1 1000
取引日：9/2 -500
取引日：9/3 2000
取引日：9/4 -600
取引日：9/5 -200
-----------------------------------

こんな感じで履歴部分と合算部分がわかれてます。
ユーザー数が半端ないので、履歴部分は月単位、合算部分は夜間のストアド等で計算していると
推測します。

画面設計が既に出来上がっていて、エンドユーザーがどうしてもそういった表示をしたい
ということでしたら、後々のためにも残ポイント列を持たせておいたら安心ですね。

スタンダードというものを提示できずに申し訳ございません。

この回答へのお礼

ありがとうございます。

>ちなみに、私が上記設計をすると断見してしまったのは・・・

いえ、目からうろこです。
私が勝手にこういったものは通帳のように毎回残高を表示するものかと
解釈していただけで履歴部分と合算部分をわけて表示すればいいということが
気がつきませんでした。

楽天ポイントの履歴を先ほど確認しましたらまさしく
ポイントの+か-しかないですね。

ありがとうございました。

助かりました。

すばらしい回答ですが、締め切らずもう少し他の回答もまってみます。

お礼日時：2012/08/16 23:10

No.4 回答者： hogya 回答日時： 2012/08/18 17:44

回答というより補足なので、参考までに読んでください。

＞もちろんさかのぼって修正ということもありえますね。

そうしたシステムもあるかと思いますが、事実の記録に基づいたシステムでは基本的にはありません。
（データが確定する処理が何段階もあるような場合は途中修正ができるものもあります）
事実の訂正も訂正のデータを入力することによって記録します。
銀行の取引でもそうなっていますよね？（実際に紙に記録した通帳の訂正はできないので）
そうすることで、正確な事実の記録やデータ改竄の防止だけでなく、計算がシンプルになるというメリットもあります。

この回答へのお礼

>事実の記録に基づいたシステムでは基本的にはありません。

おっしゃるとおりですね。

勉強になりました。

お礼日時：2012/08/20 22:44

No.3 回答者： yambejp 回答日時： 2012/08/16 22:45

システム上の残高というのは最初からの積み上げです。

1/1 入：5000
2/1 出：500
3/1 入：1000

だとして、電算上さかのぼって処理をする可能性は十分あります
1/15 出：2000とあとから入れた場合、2/1の残高4500は2500に
3/1の残高5500は3500に更新されなくてはいけません。
そのような連鎖的な更新が起こらないよう、入出データのみで処理します
ただし、ご指摘の通りシステムの運用期間がながくなると相応の負荷がかかります
そこで、システム的にある期間以前には遡って処理できないような締め処理をいれます
そうすることで締めデータの残高とその後の入出データのみで現在の残高を表示できます

この回答へのお礼

回答ありがとうございます。

なるほどですね。

もちろんさかのぼって修正ということもありえますね。
そのたびに全データを更新かけていたらたいへんですね。

一定の期間がきたら締めるという処理についてはたいへん勉強になりました。

参考にさせていただきます。

お礼日時：2012/08/17 12:59

No.1 回答者： Unripe01 回答日時： 2012/08/16 21:11

はじめまして。

いわゆる「ポイント残高」というのは計算によって導き出される数値ですよね。

源泉ではないので、基幹データとして扱う場合は不要だと思います。

残高の重要度によってかわると思いますが、

ポイントの残高をユーザーに指し示すだけの目的でつかうのであれば
入ポイント、出ポイントのテーブルをView化して
残ポイント込のテーブルを参照するようなアプリケーション設計に、私ならします。

わざわざ計算して入れるのも面倒だし、
源泉としてのデータじゃないものも使いたくない

という理由からです。

ただ、View設計が絡んでくる（このテーブルだけVIEWというのも反発のもとかと。）ので、そのへんの兼ね合いも含めて頑張ってください。

この回答へのお礼

早速の回答ありがとうございます。

>いわゆる「ポイント残高」というのは計算によって導き出される数値ですよね。
はい、そのとおりです。


>源泉ではないので、基幹データとして扱う場合は不要だと思います。
すみません。
ここでおっしゃっている源泉というのはどういった解釈をすればいいのでしょうか？


>ポイントの残高をユーザーに指し示すだけの目的でつかうのであれば
>入ポイント、出ポイントのテーブルをView化して
>残ポイント込のテーブルを参照するようなアプリケーション設計に、私ならします。

ブラウザ上で表示したい内容は

入ポイント　| 出ポイント |　残高ポイント
5000　　　|　　　　　　|　　5000
　　　　　　｜　500　　　｜　4500
1000　　　｜　　　　　　　｜　5500

のようになります。
いわゆるwhileで　limit 0,50のように数を制限しながら出力しようかと思います。
会員一人あたりのレコードが数千とか膨大になったときに最初のレコードから数千行目のレコードを
ひとつひとつ計算しないと残高の表示はできないのでは？

わかりにくい説明かもしれません・・・

お礼日時：2012/08/16 21:33