アカウント名:
パスワード:
私の場合、すべてのシステムが同じデータベースをみることで全体最適化を行っています。(中略)ある情報を取り出すとき、データベースに書いてあるものは値が変わることはありません。ですが情報基盤では取り出す途中にオブラートが入り異なった情報にすることが可能です。(中略)そのときに「正しい値はここにある」っ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
問題はソフトでしょ (スコア:0)
>メーカーの開発費を軽減、地元IT(情報技術)企業が参入しやすくする。
とあるので、新たに開発しなおしと言うことですか。
コスト的にどうなんだろ?
分割発注でインターフェース部分がひどい事になりそうだ・・・。
Re:問題はソフトでしょ (スコア:2, 興味深い)
という話は、Pick up 自治体 : 長崎県(第1回) [hitachi.co.jp]の島村秀世氏に対するインタビューに書いてありました。
システム間インターフェースに関する部分だけ抜き出してみます。
Re:問題はソフトでしょ (スコア:1)
> どのプログラムが参照しているのかを管理するのが大変になり
> そうです…。
その管理が必要な理由が解りませんが…。
ちゃんとしたトランザクション管理ができていれば問題ないように思います。
Re:問題はソフトでしょ (スコア:2, 参考になる)
あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
一般的に、従来からよく用いられてき
Re:問題はソフトでしょ (スコア:0)
>あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。
>これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
実はどちらかに傾倒するのはよくないのよね。
どちらもちゃんと考えてやらないとダメなんですね。
Re:問題はソフトでしょ (スコア:0)
失礼 POA です。ご指摘アリガト。
>実はどちらかに傾倒するのはよくないのよね。
そう思ってたんですけどね。
実際にDOAとPOAによってデータベースを設計していくと経験的には、やはり、DOAのほうがシステムのライフサイクル内でのテーブルの変更は少なくて済みましたね。というか、徹底してDOAを使ってある場合テーブルの変更は基本的にはまずありません。ただし、ビジネスモデルの変化によって、テーブル自体は、どんどん増えていきますし、使わなくなるテーブルも出てきます。
うまくDOAを使って設計されたシステムでは、ビジネスロジックの変更があっても影響するテーブルが基本的には追加されたテーブルに関してのみですむので、アプリケーション側の変更点が最小限で済みます。
ところで、知ったかぶりしてすぐにtypoしてしまう私の少ない経験上の話なのであんまり信用しないでくださいね。(^_^;)
Re:問題はソフトでしょ (スコア:0)
うっ日本語になってない。はずかし..
以下修正
うまくDOAを使って設計されたシステムでは、ビジネスロジックの変更があっても影響するアプリケーションは、基本的に追加されたテーブルが影響する範囲内に収まるので変更点は最小限で済みます。