アカウント名:
パスワード:
私の場合、すべてのシステムが同じデータベースをみることで全体最適化を行っています。(中略)ある情報を取り出すとき、データベースに書いてあるものは値が変わることはありません。ですが情報基盤では取り出す途中にオブラートが入り異なった情報にすることが可能です。(中略)そのときに「正しい値はここにある」って渡せるものは何だろうかと考えたのですが、それが「データベース」でした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
問題はソフトでしょ (スコア:0)
＞メーカーの開発費を軽減、地元IT（情報技術）企業が参入しやすくする。
とあるので、新たに開発しなおしと言うことですか。
コスト的にどうなんだろ？
分割発注でインターフェース部分がひどい事になりそうだ・・・。
Re:問題はソフトでしょ (スコア:2, 興味深い)
という話は、Pick up 自治体 : 長崎県(第1回) [hitachi.co.jp]の島村秀世氏に対するインタビューに書いてありました。
システム間インターフェースに関する部分だけ抜き出してみます。
当然私は中身を覗いてないので正確な物言いはできないのですが、あるテーブルに対するデータはどのプログラムが更新・挿入し、どのプログラムが参照しているのかを管理するのが大変になりそうです…。
DAOは共有するというコーディング手法をとっているのかな？
それと遠隔地にあるシステムとの連携は、どうしてもファイル連携の形をとらざるをえないと思うのですが、どうなんでしょうね。
Re:問題はソフトでしょ (スコア:1)
> どのプログラムが参照しているのかを管理するのが大変になり
> そうです…。
その管理が必要な理由が解りませんが…。
ちゃんとしたトランザクション管理ができていれば問題ないように思います。
> DAOは共有するというコーディング手法をとっているのかな？
DAOってData Access Object？これってMSの独自技術なんじゃ…？
良く解らないので教えてもらえませんか？
Re:問題はソフトでしょ (スコア:2, 参考になる)
あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
一般的に、従来からよく用いられてきた手法はPOEが多く、DOAは、割と新しい手法といわれています。
DOAのメリットは、手続きに比べ安定しているデータを中心に考えていくためビジネスモデルの変化に追従していくのが簡単だといわれています。
Re:問題はソフトでしょ (スコア:0)
＞あるビジネスモデルを分析する際に、データを中心として捕らえ分析していく手法です。
＞これに対する考えが、POE(Process Oriented Approach)といって、手続きを中心に分析していく方法です。
実はどちらかに傾倒するのはよくないのよね。
どちらもちゃんと考えてやらないとダメなんですね。
Re:問題はソフトでしょ (スコア:0)
失礼 POA です。ご指摘アリガト。
>実はどちらかに傾倒するのはよくないのよね。
そう思ってたんですけどね。
実際にDOAとPOAによってデータベースを設計していくと経験的には、やはり、DOAのほうがシステムのライフサイクル内でのテーブルの変更は少なくて済みましたね。というか、徹底してDOAを使ってある場合テーブルの変更は基本的にはまずありません。ただし、ビジネスモデルの変化によって、テーブル自体は
Re:問題はソフトでしょ (スコア:0)
うっ日本語になってない。はずかし..
以下修正
うまくDOAを使って設計されたシステムでは、ビジネスロジックの変更があっても影響するアプリケーションは、基本的に追加されたテーブルが影響する範囲内に収まるので変更点は最小限で済みます。
Re:問題はソフトでしょ (スコア:1)
>ちゃんとしたトランザクション管理ができていれば問題ないように思います。
テーブルの設計変更がおきたときの影響範囲を特定するためです。
データベース自体をインターフェースにし、複数システムがそれを参照しているというのであれば、必要になってくるのでは？
>DAOってData Access Object？これってMSの独自技術なんじゃ…？
そういえば用語が間違ってますね。
モデルとでも脳内変換しておいていただければありがたいです。
Re:問題はソフトでしょ (スコア:1)
> データベース自体をインターフェースにし、
他のシステムでも、インターフェース設計に変更が起これば同じ事のように思うのですが。
でも、示してもらったページ [hitachi.co.jp]を読むと、インターフェースとかそういう話ではなく、データ中心設計と言う話なんじゃないでしょうか。
データ中心と言う考え方は、プログラムやユーザインターフェースは変更が多いけど、データ(データベース)の設計には変更が少ない、ってことですよね。であれば、データベースに対する変更は少ないはず... ですが....
> モデルとでも脳内変換しておいていただければありがたいです。
モデル? モデルを共有するコーディング手法？うーむ…ちょっと意味が解らないです。
Re:問題はソフトでしょ (スコア:0)
Re:問題はソフトでしょ (スコア:1)
> データベース自体をインターフェースにし、複数システムが
> それを参照しているというのであれば、必要になってくるのでは？
たいていは View で何とかできるのでは？
＃設計しだいでいろんな運用の仕方があるとは思う。
# mishimaは本田透先生を熱烈に応援しています
Re:問題はソフトでしょ (スコア:1, 参考になる)
簡単に言えば、ビジネスオブジェクトからデータソースへのアクセスを分離することによって、データソースの違いによる影響範囲を狭め、ポータビリティを高めようというものです。
ビジネスアプリケーションでデータベースを変更するなんてことはめったに無いので、これだけでは利点がなさそうに聞こえますが、ロジック部分の外部環境への依存度を下げることが出来るため、単体テストが圧倒的に楽になります(モックのデータソースを使います)。
Re:問題はソフトでしょ (スコア:0)
いやいや。
Re:問題はソフトでしょ (スコア:0)
Re:問題はソフトでしょ (スコア:1, 興味深い)
>どのプログラムが参照しているのかを管理するのが大変になりそうです
大変です。
>DAOは共有するというコーディング手法をとっているのかな？
紙のスキーマを信じてバラバラにコーディングするという手法をとっています。
--
関係者なのでAC
Re:問題はソフトでしょ (スコア:0)
もしやlancard.com [lancard.com]の方でしょうか。