PB 電子会議室
発言No. | 更新日 | 題名(クリックすると発言内容と関連するコメントが表示されます) |
---|---|---|
20445 | 03/10/14 16:14:06 | RE(5):サーバー統合の背景・論点 By まぁく |
20440 | 03/10/13 19:44:22 | RE(4):サーバー統合の背景・論点 By Taka |
20436 | 03/10/13 16:15:35 | RE(3):サーバー統合の背景・論点 By まぁく |
20430 | 03/10/10 16:41:17 | RE(2):サーバー統合の背景・論点 By M.M |
20387 | 03/10/08 11:06:49 | RE(1):サーバー統合の背景・論点 By まぁく |
20386 | 03/10/08 11:05:43 | Oracleのインスタンス/スキーマの管理について By まぁく |
カテゴリ:その他
日付:2003年10月13日 19:44 発信者:Taka
題名:RE(4):サーバー統合の背景・論点
まぁくさん、こんばんは。
システムの規模やデータ件数,利用頻度などにもよると思うので一概に「コレが正解」ってのは
無いと思いますが、経済的な理由からどうしてもサーバを統一しなければならない前提であれば、
インスタンス:事業所の数だけ設ける
スキーマ:システム単位で分ける
の組み合わせが妥当かなと思います。
インスタンスを分けるのは、まぁくさんが「メリット」で書かれた内容通りです。
(統合する以上「管理が増える」のは当然ですので、これをデメリットにはしない)
スキーマも、設計上・運用面どちらから見てもテーブル等のオーナーは明確にしておくべきです。
共有化についてはシノニムとアクセス権限をきちんと整備しておけば問題ないでしょう。
ケースにもよりますが、アプリから接続するDBユーザには直接テーブルを持たせない,といった
環境的な配置構成は実際にあります。
ここで挙げたのはあくまでも小?中規模クラスの場合の一例です。
付加情報:
PowerBuilder Version (記載なし)
Client SoftWare
OS (記載なし)
DBMS (記載なし)
Browser (記載なし)
Server SoftWare
OS (記載なし)
DBMS (記載なし)
WebServer (記載なし)
Copyright © 2013 Power Future Co., Ltd.