モジュラーアプリケーションを構築しています。構成を通じて、これらのアプリケーション モジュールのオンとオフを切り替えることができます。各モジュールのデータを保持するテーブルに使用するデータベース構造 (mssql2005) を決定しようとしています。私が考えた2つのオプションは次のとおりです。
すべてのモジュールに共通のデータがあるため、ソリューション 2 を使用すると、その共通データ (ユーザーなど) を管理する方法がわかりません。
--
明確にするために、これらのモジュールは個別に販売される可能性があり、構成設定はクライアントによって制御されないものです。これが、それらを別々の表に分割することさえ考えている理由です。
あなたが提案したものに代わる私の推奨事項は、SQL Server 2005 で利用可能なスキーマ機能です。
詳細については、このリンクをお読みください...
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1184503,00.html
私だったら、最初にアプリケーションを完全に正規化します。すべての共通データを共有テーブルに配置し、各モジュールに固有のデータのみを特定のモジュール テーブルに残す構造を開発します。
共有テーブル内のデータがすべてのモジュールに真に共通であり、これらの「共通」テーブルにまとめようとしているエッジ ケースがない場合、1 つのモジュールをオンまたはオフにしても、他のモジュールの機能に影響を与えることはありません。データの重複が (あったとしても) ほとんどなくなります。
私は1つのデータベースを持っています。これにより、ソリューションの管理が大幅に簡素化されます。
次に、データを正規化します。これにより、データの整合性の問題が簡素化されます。
次に、必要に応じて各モジュールのテーブルをベース データベースに追加します。この基本データベースは配布しますが、未使用のモジュールのデータは配布しません。各モジュールは、インストール時に独自のデータを配布します (おそらく、モジュール自体に組み込まれるのではなく、インストーラーによって)。
テーブルの接頭辞はどちらにしてもあまり重要ではなく、データベースを共有することの良いところは、どのモジュールからでも各テーブルにアクセスでき、共有構成ファイルなどを持つことができることです...
テーブル全体のクエリが必要な場合は、それらを 1 つのデータベースに配置することをお勧めします。それ以外の場合は違いはありません。ただし、データベースが 1 つあると、保守がはるかに簡単になります。
複数のデータベースが必要な場合を除き、1 つだけを使用することをお勧めします。