EIP
共有データベース †
一言要約 †
スキーマを統一したDBを使えば一貫性のある最新データ利用できる・・・ちゃんとスキーマをデザインできたらね。
要約 †
企業は色んな言語やプラットフォームを使って個々にアプリケーションを複数構築しており、迅速かつ一貫した情報の共有を必要としている。
どのように統合すれば、情報を共有および交換できるだろうか？
File Transferはデータ共有を可能にするがタイムリーさに欠け、現代のビジネスにおいて誰もが最新データを持つことは必須である。
更新を速く頻繁にすれば問題は減らせるが、各アプリケーションがどのマスターデータを参照すればいいのかを機にしなければならない問題が残る。
File Transferはデータ形式を十分に強制できず、時にはセマンティック不協和音(semantic dissonance)としてビジネス上重大な影響を与える可能性がある。詳しく知りたい人はData and Realityを嫁。
全アプリケーションが必要な時にいつでも共有されたデータにアクセスできるよう中枢となるデータストアが必要である。
統合されたアプリケーション群が同じデータベース上にあると、一貫性についても同時に確実となる。複数からの同時更新はトランザクション管理システムにて扱えばよい。
Shared DatabaseはRDBMSの普及により非常に簡単に実現でき、ほぼ全ての開発プラットフォームはSQLを扱えるので複数のファイル形式について心配する必要はない。
どのアプリケーションも同じデータベースを使うことで、実稼動して大量のデータが集まってからセマンティック不協和音の問題にあたふたする前に立ち向かえる。
Shared Databaseの最も大きな問題の1つは、共有データベースに適した設計を考え出すことであり、複数アプリケーションのニーズを満たす統一スキーマを考えるのは難しい。技術的にはそうでなくても政治的に難しいこともある。重要なアプリケーションが統一スキーマのせいでスケジュール遅延を被る恐れがあると、分離への政治的圧力がかかる。部門間で起こる競合がこの問題をしばしば悪化させる。
別の問題は外部パッケージであり、ほとんどのパッケージアプリケーションは自スキーマ以外は動作しない。
この問題はアプリケーション統合や企業合併にまで拡がる。
Shared Databaseを使うと複数から頻繁に読み書きされるためDBパフォーマンスのボトルネックやデッドロックが発生する。アプリケーション単位でデータベースを配置したり分散データベースを使ったりしてもそれぞれ別の問題が発生する。
データでなくアプリケーション機能を統合するには、Remote Procedure Invocationを使う。1つの共通スキーマでなくデータタイプ毎に1つのフォーマットを使った小さい単位のデータを頻繁に交換するため、Messagingを使う。
担当者のつぶやき †
- NoSQLが流行ってる昨今、また違った論点でアップデートできるような気がする。
- RDBほどスキーマに神経質にならなくていいよね、とか
- スケール比較的簡単にできるよね、とか
- プロダクトによっては変なクセ(JOIN使えない、いちいち処理が重い)あるよね、とか
- (商用含めて)そもそもどれ使っていいかわからんくらい大杉、とか
みんなの突っ込み †
