私は、DBA、開発者、およびアーキテクトとして、両方の側 (コンシューマーとプロバイダー) からこれを繰り返してきました。
プロバイダーとしての私の偉大な功績の 1 つ (1996 年) は、最大の保険会社 (数百万ドルの商品) を対象とした商用保険金請求管理ソフトウェア製品のインストール CD を作成したことです。そのインストール CD には、Oracle 7.2 RDBMS エンジン、FileNet 光ストレージ システム (紙のドキュメントをスキャンして、カタログ化されたバイナリ バージョンを作成する)、およびカスタム請求処理アプリケーション (VB 4.0 で構築) がインストールされ、すべて統合され、すぐに実行できます。インストール プロセスの一環として、ユーザーは Oracle ソフトウェアのインストールをスキップしたり、カスタマイズしたりできます。また、ユーザーはデータベース構成のすべての主要な詳細 (データベース、スキーマ、テーブルスペース、サイズ、ディスクなど) をカスタマイズ/上書きできます。
また、必要に応じてクライアントのサイトに出張するなど、この製品のフィールド サービスも提供しました。インストール CD を文字通り何百回も再現できるあらゆるシナリオでテストしましたが、出張はおろか電話さえ必要な現場での故障は一度もありませんでした (出張は 4 回ありましたが、事前販売のため)。代わりは）。
最近 (2007 年)、私は巨大企業の内部システム用に Oracle 10g データベースを作成するスクリプトを作成しました。本番環境では、データベースのサイズは 8 TB で、主にデータ量の多い単一のトランザクション テーブル用です。テストでは、データベースのサイズは中程度のサーバーで約 1 TB でした。開発中、データベースは私のラップトップで実行できるように約 100 MB のサイズになりました。EXACT SAME SCRIPTS は 3 つの環境すべてを作成し、それらを拡張して新しい環境/マシンを約 5 分で処理することができました。このデータベースには極端なパフォーマンス チューニングが含まれていたため、関連するすべての特性のカスタマイズが絶対的に重要でした。
保険金請求処理製品の話に戻りますが、私はもともと SQL Server データベースから Oracle データベースへの変換をリードするために雇われていたことを付け加えておきます。ほとんどの潜在的なクライアントは、SQL Server ベースの製品を専門的で本格的なソリューションとは見なしていなかったため、この変換はビジネス上の必要性として認識されました。これは今日ではあまり一般的ではありませんが、一般的には依然として当てはまります。対象となる顧客 (特にエンタープライズ クラスの顧客) が好む複数のデータベース オプションに対応できるソフトウェア製品は、市場に浸透する可能性が高くなります。
同様に、インストール CD も不可欠な要素と見なされていました。しかし、そのような状況やその他の状況から、ほとんどの「実際の」DBA はインポート ベースのデータベース インストールを受け入れないことがわかりました。DBA およびアーキテクトとして、私は同じ理由で間違いなくそうしないことを知っています。
簡単に言えば、インポート ベースのデータベース インストールでは、顧客は結果のデータベースをほとんど制御できません。それは顧客にとって不透明であり、顧客はそれが何をしたのか疑問に思っています。これにより、顧客は、自分ができるわずかな制御を行使しようとするために多大な努力を費やすことを余儀なくされます. これは壊れやすく、エラーが発生しやすいことで有名です (Oracle のインポートは、所有権と許可の問題、制約の問題などでよく知られています)。これらすべての影響を考慮すると、インポート ベースのデータベース インストールは専門的ではありません。顧客のニーズを第一に考えていません。
データベースのインストールをスクリプト化することで、適切な種類の透明性、構成可能性、選択的な再現性、およびプロフェッショナリズムが要求する全体的な顧客管理が提供されます。また、インポートでは理解できない方法で、データベース設計の決定の影響を適切に理解することをお勧めします。
幸運をお祈りしています。