私が答えたい質問の1つは、自分のレポートや使用のために、キュートマー全体のデータを確認する必要があるかどうかです。この場合、あなたはナンバーワンで行く必要があります、さもなければあなたは良い報告を得るために悪夢を見るでしょう。
お客様によるカスタマイズはありますか？これは、物事を分離することがより良い選択かもしれないことを示します。カスタマイズしない場合は、分離しないでください。
私はこれらすべてのオプションでシステムを使用してきましたが、最初のシステムは長期的なメンテナンスに最適です。ただし、組織化され、適切に計画されていれば、すべてが実行可能です。別のオプションを選択する場合は、すべてのクライアントに変更をプッシュできる必要があります。したがって、ソース管理に保持されているスクリプトを介してデータベースに変更を加える必要があります。クライアントがアップグレードするかどうかを選択できるように、データベースのバージョンごとにソース管理を維持する必要がある場合もあります。もちろん、オプション1では、古いバージョンをそのまま使用するオプションはありません。それがあなたのビジネスニーズによりよく合うなら、それはオプション1のプラスです。
私はOllieJonesに強く同意します。オプション1を使用する場合は、クライアントが他のクライアントのデータを見ることができないように、優れたデータベースセキュリティ設計が必要です。かつて、クライアントを唯一のクライアントであるサーバーから共有データベースに移動したところ、client_IDの要求を逃した1つのproc（古いシステムでは必要なく、開発者がだらしなくなっていた）がすべてのメールを送信することになりました。最初のクライアントに関する情報を持つ他のすべてのクライアントの営業担当者。これは会社に多額の費用をかけ（問題を解決するため、電子メールの謝罪を送信するための両方であり、結果としてクライアントをほとんど失い、それらを維持するためにいくつかのコストブレイクを与える必要がありました）、多くのうめき声の謝罪と開発者はほんのわずかです彼の仕事を失うのを逃した。これを、難しい方法を学ばないレッスンにしましょう。