アカウント名:
パスワード:
こういう言い方したらアレですが、もし後者なら100万件分増やすのも600万件分増やして許容数を一桁上げるのも費用的には実は大して変わらんのと違うのかなぁ。
桁数が変わるとレコード設計が変わるので大事です. 正しいプログラムならかなり機械的に修正できるはずですが, プログラム的には間違っているけどたまたま動いている, 例えば本来使用すべきレコード型ではないけど桁数が合っているので動いていたなんて物が火を吹く可能性が高いです.
というか, この種の古いシステムはたとえ10年前に改修されていたとしても, その当時の技術レベルで作られているなんて甘い期待はしちゃだめです. 特に設計については旧来のシステムとの継続性を最重視するので, 20〜30年程度前の思想に基づいて作られています. そのため, 最
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
改修って… (スコア:3, 興味深い)
処理件数がHDD容量に依存、ってことは
今回の改修ではそこしかいじってないわけですよねぇ。
となれば、これ以上の増強は不能なのか、まだ増強の余地があるものを小出ししてるだけなのか、
非常に気になるのですが。
こういう言い方したらアレですが、もし後者なら
100万件分増やすのも600万件分増やして許容数を一桁上げるのも
費用的には実は大して変わらんのと違うのかなぁ。
Re:改修って… (スコア:5, 興味深い)
桁数が変わるとレコード設計が変わるので大事です. 正しいプログラムならかなり機械的に修正できるはずですが, プログラム的には間違っているけどたまたま動いている, 例えば本来使用すべきレコード型ではないけど桁数が合っているので動いていたなんて物が火を吹く可能性が高いです.
というか, この種の古いシステムはたとえ10年前に改修されていたとしても, その当時の技術レベルで作られているなんて甘い期待はしちゃだめです. 特に設計については旧来のシステムとの継続性を最重視するので, 20〜30年程度前の思想に基づいて作られています. そのため, 最
Re:改修って… (スコア:4, 興味深い)
結局、一から作り直したものに更新するしかないように思いますが、完全に新式のものと、旧式のものを二つ並行して半年ぐらい走らせながら検証して移行する、というわけにはいかないものでしょうか？
ソフト屋さん、システム屋さんには、すごく大きなビジネスチャンスのように思いますが。
Re:改修って… (スコア:3, 興味深い)
新システム系と旧システム系でまったくおなじデータを処理するならともかく、新システムに伴い周辺の接続システムも機能追加などでインターフェース要件が変更になることがままあります。すると、並行稼動のためには、両系のシステムのデータをさばく必要が出ます。しかし、現実には、そのためのインフラを保守する費用の問題や、それゆえのパフォーマンス問題などで、結局、どちらのシステムも危機的な状況に陥ってしまうことになります。
お客さんが、夢見なけりゃできるんだけどね＿|￣|○
でも、すんごいお金投資してオープン化するんだし、その分、便利になってよ、っていう気持ちもわかるのよ。そうして、すべてのシステムを一夜にして切り替える、というすばらしい計画ができる、と。
# やっぱりAC。
Re:改修って… (スコア:2, 参考になる)
私の知っている限りでも、某大手金融機関でそのような事例があります。
東証との接続や全銀との接続など、外部とのインタフェースは基本的に変わらないので、そこにブリッジをおいてメッセージをコピーする方法をとります。
日締めをすると計算があわなかったりするんですよね。