- PR -

データの持ち方につきまして

投稿者投稿内容
骨骨★Rock!
常連さん
会議室デビュー日: 2007/09/11
投稿数: 38
投稿日時: 2008-07-01 20:08
引用:

ポイント履歴テーブルにトリガーを仕組んで、
顧客テーブルのポイント残高を更新すると楽そうですね。

ECサイトなら残高の参照回数は多いでしょうけど、
残高の更新回数は少ないですしね。




かつのり様、

ご回答いただきましてありがとうございます。
勉強になります。トリガーを使うという方法もありますね。

カーニー様から頂いたアドバイスにも、ポイント履歴テーブルの存在が出てきましたが、ポイント履歴テーブルを作った方がベターなのでしょうか?
私も作った方が良いものか迷いましたが、最終的にはなくても問題ないかなと
判断しました。(整合性がとれるかどうかも不安も含めて)
ポイントの履歴のページでは、注文テーブルと注文明細テーブルの内容を
下記のように時系列に並べて表示するだけでも事たりるように思いました。


---------------------------
7/1 ポイント利用  50pt
7/1 購入ポイント取得 100pt

[ メッセージ編集済み 編集者: 骨骨★Rock! 編集日時 2008-07-01 20:12 ]
カーニー
ぬし
会議室デビュー日: 2003/09/04
投稿数: 358
お住まい・勤務地: 東京
投稿日時: 2008-07-01 20:25
引用:

骨骨★Rock!さんの書き込み (2008-07-01 20:08) より:
カーニー様から頂いたアドバイスにも、ポイント履歴テーブルの存在が出てきましたが、ポイント履歴テーブルを作った方がベターなのでしょうか?
私も作った方が良いものか迷いましたが、最終的にはなくても問題ないかなと
判断しました。(整合性がとれるかどうかも不安も含めて)


僕がポイント履歴テーブルを提案したのは、ポイント集計の元情報は一箇所にあったほうが間違いが起きにくいだろう、集計もしやすいだろう、いざ不整合が発生したときに目視確認とかがしやすいだろう、という理由によります。

もしポイント履歴テーブルを作るのであれば、注文テーブル、注文明細テーブルにはポイント情報は持たせず、代わりに履歴テーブルとの間にリレーションを定義するのがよいのではないでしょうか。
骨骨★Rock!
常連さん
会議室デビュー日: 2007/09/11
投稿数: 38
投稿日時: 2008-07-01 20:33
引用:

僕がポイント履歴テーブルを提案したのは、ポイント集計の元情報は一箇所にあったほうが間違いが起きにくいだろう、集計もしやすいだろう、いざ不整合が発生したときに目視確認とかがしやすいだろう、という理由によります。

もしポイント履歴テーブルを作るのであれば、注文テーブル、注文明細テーブルにはポイント情報は持たせず、代わりに履歴テーブルとの間にリレーションを定義するのがよいのではないでしょうか。



カーニー様、
ご返信ありがとうございます。
自分で馬鹿な勘違いをしておりました。
私も一番はじめに注文明細テーブルにポイント情報を持たせるか
代わりにポイント履歴テーブルにもたせるかで迷った事を今、思い出しました。
変な質問をしてしまい、すみませんでした。

スキルアップ/キャリアアップ(JOB@IT)