元来Oracleや、SQL Serverにも対応可。
今後、Oracle導入済みのサーバにアプリＡを移行して動作予定。
そこで、自社開発予定のシステムなどから、アプリＡが保存することになるDBの
中身を直接読み込む（SELECTのみ）ことの問題点をお聞きします。
質問１．
DB接続のユーザのパスワード等は、Oracleを管理している自社が、アプリＡ（を設定する代理店）に付与するもの
だと想像しています。なので当方が接続のパスワードがわからないことは無いですよね。接続可ですよね。
質問２．
元来の独自のバイナリファイル形式からDBのテーブルに変わるので
有る程度のデータは判読可と予想しますが、逆アセンブリできなくする技術のように、あえて判読困難にしてあるのでしょうか。
質問３．
アプリＡと自社システムの場合のように複数のシステムで使用する場合、DBCAなどを使ってデータベースを新規に作成するのですよね？
それとも同一のデータベース上ですか？
質問４．
ライセンスは、Standard Edition Oneですが、データベースの作成数に制限はありませんよね？
宜しくお願いします。
No.1
1078
199
アプリAの Oracle DBに、ユーザー企業のアプリや統計・集計処理を行うためにアクセスする場合、2通りの方法があります。
1つは、夜間にバッチジョブで書き出したり、統計・集計処理を行う場合です。
2つめの方法は、オンラインでDBのデータにアクセスする方法です。こちらの方法では、中規模以上のシステムでは、レプリカのDBを作成してユーザー企業のアプリはレプリカDBにアクセスするようにします。
アプリAは実体のDBを使用し、ユーザー企業のアプリはレプリカDBを使用します。
ユーザー企業のアプリの原因でDBやデータに障害を起こさないため、アプリAのレスポンス確保のため、データの一貫性・整合性保証のためです。
特にDBはインデックスの設定とアクセスパスの選択で、レスポンスが極端に悪くなります。ユーザー企業のアプリが、DBのレスポンスを低下させて、アプリAを止めてしまうリスクがあります。
管理者権限のユーザーIDの管理は、通常はユーザー企業の責任範囲です。セキュリティー管理責任まで含めたアウトソーシング契約をしない限り、ユーザー企業がユーザーIDとパスワードの管理責任を持ちます。
1
1
2
134
129
ありがとございます。レプリカのDB、勉強してみます。