メインコンテンツへスキップ

銀行の残高

コメント

19件のコメント

  • ISHIJIMA

    何がベストかは難しいですね

    今まで作成したシステムは

    基本的に月次更新等で確定数字が必要なので月次更新は必要ですね

    あとはリアルデータを持つか持たないか

    特定日までは月次と履歴等で計算できるようにするのかなと

    銀行等は前のデータを修正する事がないような気がしますので

    その時の残高を持っているとかですかね(やったことがないので推測ですが・・・)

  • Pu

    こんにちはPuです
    なんせよ疑問を持つ事は大事ですね
    銀行の場合かなり昔からオンライントランザクションを処理するプロセッサー(OLTP)ベースの考え方で
    insertオンリーで訂正と言う概念はなかったと思います(知らんけど(^_-)-☆)
    ですので取引明細とは別に最終残高があれば事足りると思います(知らんけど(^_-)-☆)
    会計の考え方からすれば一般の販売管理でもデータ訂正はせず、赤黒のデータを発生させる方が
    正しい考え方だと思います(利便性を考えなければ)履歴が残るので。
    あくまでも私個人の考え方です。
    でわ~でわ~

     

  • nkmt

    ISHIJIMAさん、Puさん いつも大変お世話になっております。
    早速ご意見頂き誠にありがとうございます。
    銀行の残高の件は意見は一致した感じですね。
    販売管理での理論在庫数は、リアルタイムに求められる事が多いです。
    レコードロックやシステムアボートが絶対起きないシステムを作れた事もありませんし
    リランで再計算してもらうファイル構造等を取る事が多いです。

    在庫数は年初分しか保持せずに
    1月1日~指定日までの入出荷を差し引きしたSQL文で現在理論在庫数を都度求める!
    なんてのも有りなのかなと、以前のISHIJIMAさんの投稿をヒントに思った事もあります。

  • ISHIJIMA

    >レコードロックやシステムアボートが絶対起きないシステムを作れた事もありませんし

    遅延トランザクションで実現可能ですよ

  • nkmt

    私の場合、(遅延ではなく)タスク前トランザクションを行う事により
    デッドロックを起こしてしまう事がありそうです。
    田中さんが商品のAとBとCとDを出荷する伝票を保存し、同時に
    山田さんが商品のDとCとBとAを出荷する伝票を保存した場合に
    拠点別+商品コード+年月別の残管理データのデッドロックとか。
    遅延トランザクションの場合、絶対にデッドロックは起きないのでしょうか?


  • ISHIJIMA

    >デッドロックを起こしてしまう事がありそうです。

    >拠点別+商品コード+年月別の残管理データ

    デッドロックはまた別の話のような気がします。

    ただ残高管理データ等があるとDB構造及び更新の方法を考えないといけないかもしれません。

  • nkmt

    承知しました。ご返信ありがとうございました。

  • tanda

    Puさん

    > 銀行の場合かなり昔からオンライントランザクションを処理するプロセッサー(OLTP)ベースの考え方で
    > insertオンリーで訂正と言う概念はなかったと思います

    昔、35年くらい前になりますが、オフコン上がりの知り合いがいて、レコードを一切修正せず、レコードの追加だけで履歴を残す作りのプログラムばかりを作る人がいて、当時は奇異に感じていたのですが、そういう事情があったんですね(笑

  • tanda

    私は1982年に出たCondor S20から始まって、dBASE II→dBASE III→dBASE III Plus→dbMAGIC→Magicと流れてきたのですが、今になって、なんだかそのInsertオンリーの作りというものに興味が沸いてきました。今度、作ってみたいと思います。

  • ISHIJIMA

    トランザクションはコミットするまでは途中で問題があった場合は

    すべてロールバックされると思っています。

    遅延でも物理でも問題ないかと思います。

    ただトランザクションの範囲が広い場合は範囲とかDB構造を検討して

    デッドロックが起きないようにする事が重要だと思っています。

    ただ遅延の場合はトランザクション内で更新する前に更新されている場合は

    (デットロックがかかるような更新)

    エラーとなって画面に戻ってくるので再度実行する事ができると思っています。

    >田中さんが商品のAとBとCとDを出荷する伝票を保存し、同時に
    >山田さんが商品のDとCとBとAを出荷する伝票を保存した場合に

    この様な場合は両方ともエラーとなって戻ってくると思っています。

    再度同時に実行すればまた両方エラーとなり同時に実行されるのであれば無限にエラーとなると思います。

    ただ同時に何回もされるような事は実際ないので問題のではないかと思っています。

    違っていたらすみません。

  • nkmt

    ISHIJIMAさん アドバイス大変ありがとうございます。
    ひとまずお礼申し上げます。
    実験など行っていきたいと思います。

  • nkmt

    ある書籍からの引用。
    金融系のシステムでよく使われる処理としては、削除処理も打ち消しのINSERTとして保存し、合計値を算出する設計とすることもあると書かれていました。

  • Pu

    こんにちはPuです。
    そもそも大昔は大量のデータからそのデータを探すのに時間が掛かったんです
    一番早いのはデータのinsertでした
    データ訂正の場合1:元のデータを削除,2訂正後のデータをinsert
    これも削除の為元のデータを探さないといけません(削除はデータ先頭にFFをupdateする)なので
    訂正なんです。
    ですので訂正も赤伝(マイナスデータ)をinsertして訂正後のデータをinsertすると言う作りが
    残高更新も加算だけで済みますのでプログラムもシンプルになります。
    シンプルであると言う事は処理も軽く(プログラムステップ数も少ない)、バグも出にくい
    日本人Eは複雑な事をより複雑にする事は得意なんですが
    複雑な事をシンプルに考えると言うのが苦手な人種なんですかね
    日本のテレビのリモコンがその代表ですね(;^_^A
    その複雑さをマニュアルでカバーしようとする
    マニュアルなんかがなくても大丈夫と胸を張れるシステムを目指したい今日この頃
    「シンプルであることは、複雑であることより難しい」
    でわ~でわ~

  • nkmt

    ありがとうございます。
    > 1:元のデータを削除,2訂正後のデータをinsert
    各種伝票入力の明細行数の分だけ、実データ明細DELETE、
    WFから実データへINSERTこの処理を行っています。
    物によっては実データを直メンテ、保存したくない場合はRollbackする作りにする事もあります。
    お客様の要望を聞くと、そんな風に考えているんだとシンプルにしたくなる事があります。

  • tanda

    私は、40年以上前は汎用機やオフコンの利用者側の経験しかありませんでしたので、当時そんな事情があったとは知りませんでした。勉強になりました。

  • nkmt

    私は26年位前迄はNECのオフコン、ビジネスパソコンを使っていました。
    COBOLだったので、READ INVALID、READ NEXT、WRITE、REWRITE、DELETEを記述しておりました。
    Magicの書き込みリンクは、READ INVALIDとWRITE、REWRITEの組合せなんだと理解するなどしてました。

  • nkmt

    ビジネスパソコンは8インチでOS起動して、取りだして、エディタ動かして
    コンパイルして、リンクして、実行して・・・なんて事やってましたね。
    それはさすがに30年以上前の話ですけど。

  • tanda

    そうですね、30年くらい前から、COBOLからdbMAGICに転向してこられた方が多かったですね。今でも記憶にあります。

  • tanda

    8インチでの起動は、当時のCP/M-86やMS-DOSのパソコンでもありましたね。今でも8インチディスクは記念に取ってあります(笑

サインインしてコメントを残してください。