SQL Server で複数の「顧客」を表す Windows アプリケーションを設計する必要があります。各顧客は同じデータ モデルを持っていますが、独立しています。
複数のデータベースを使用する場合と単一のデータベースを使用する場合の長所/短所。
この作業を行うのに最適な方法はどれですか。単一のデータベースを使用する場合、そのために行う手順は何ですか。
編集:
1 つのことは、データベースがクラウド (ラックスペース) アカウントでホストされることです。
SQL Server で複数の「顧客」を表す Windows アプリケーションを設計する必要があります。各顧客は同じデータ モデルを持っていますが、独立しています。
複数のデータベースを使用する場合と単一のデータベースを使用する場合の長所/短所。
この作業を行うのに最適な方法はどれですか。単一のデータベースを使用する場合、そのために行う手順は何ですか。
編集:
1 つのことは、データベースがクラウド (ラックスペース) アカウントでホストされることです。
複数の顧客からのデータを同じデータベースに保存しないでください。この間違いを修正するために多くの時間/労力/お金を費やさなければならなかった会社を私は知っています。データベースが別々であっても、データベース コンピュータを共有することに躊躇するクライアントさえ知っています。プラス面としては、これらのクライアントは通常、追加のハードウェアに喜んでお金を払います。
セキュリティの問題だけでも、これを行うことはできません。これにより、大規模な顧客を失うことになります。
ソフトウェアをアップグレードしたくない顧客がいる場合、単一のデータベースを共有すると非常に困難になる可能性があります。個別のデータベースにより、お客様はアップグレードの準備が整うまで、古いデータベース構造を引き続き使用できます。
ソリューションに大幅なスケーラビリティを提供できる自然なデータ パーティションを人為的に制限しています。複数の小規模な顧客がデータベース サーバーを共有したり、独自のデータベース/カタログを表示したり、別のデータベース サーバー/インスタンスで実行したりできます。
データベースの設計が複雑になります。そうしないと自然に分離されるはずの顧客データを区別する必要があるためです。つまり、where 句ごとに CustomerID を指定する必要があります。
すべてのテーブルに行を増やすことで、データベースが遅くなります。CustomerID がすべてのインデックスの一部になり、各インデックス ノードに格納できるレコードが少なくなるため、データベース メモリをより早く使い果たすことになります。参照の局所性という固有の利点が失われるため、データベースも遅くなります。
1 人の顧客のデータ ロールバックは非常に困難であり、データベースが大きくなるにつれて本質的に不可能になることさえあります。これを行うには、バックアップからの単純で標準的な復元よりもはるかに時間がかかり、リソースを大量に消費するカスタム手順が必要になります。
大規模なデータベースは、タイムリーにバックアップ/復元することが非常に困難になる可能性があり、十分に高速化するためにハードウェアに追加の費用が必要になる可能性があります。
データベースを使用するアプリケーションは、保守とテストが難しくなります。
1 つの間違いですべてのクライアントを台無しにする可能性があるため、間違いははるかに破壊的なものになる可能性があります。
データベースを単一の場所に強制することで、低レイテンシーのパフォーマンス向上の可能性を防ぎます。たとえば、海外の顧客は、低速で遅延の大きいネットワークを常に使用しています。
あなたは愚かな DBA、または失業中の DBA、あるいはその両方として知られるでしょう。
ただし、共有データベース設計にはいくつかの利点があります。
共通テーブル スキーマ、コード テーブル、ストアド プロシージャなどは、1 つの場所で維持および保存するだけで済みます。
場合によっては、ライセンス費用が削減される場合があります。
一部のメンテナンスは簡単ですが、組み合わせたアプローチを使用すると、全体的にはほぼ確実に悪化します。
すべてまたは大部分のクライアントが非常に小さい場合、サーバーを組み合わせないことでリソースの使用率を低く抑えることができます (つまり、比較的高いコストがかかります)。クライアントを許可と明確な理解と組み合わせることで高コストを軽減できますが、それでも大規模なクライアントには別のデータベースを使用します。このような状況では、クライアントに対して明確かつ率直に対応する必要があります。
サーバー コストの分担を除けば、これは依然として非常に悪い考えですが、コストも非常に重要な側面になる可能性があります。これは、このアプローチを正当化する唯一の理由です。ただし、合理的であるとしても、これは避けてください。たぶん、あなたの製品をもう少し変更した方が良いでしょう。あるいは、安い価格で小さな顧客をサポートできないだけかもしれません.
ある日、開発者が何かを台無しにし、ある顧客が別の顧客の情報にアクセスすることがあります。その結果、顧客を失うことになります。これだけでも、1 つのデータベースに複数の顧客を含めることはできないことがわかります。これを知っていれば、誰もあなたの顧客になりたくないでしょう。
この場合、最終的に発生するすべての問題を実際に検討する必要がありますか? 答えは簡単です - いいえ。同じデータベースに複数の顧客の情報を持ちたくありません。
これが発生するのは、顧客のログオン、セッションなどを追跡するためのマルチプレクサ データベースがある場合のみです。ただし、顧客が使用および保存するデータは、専用のデータベースにある必要があります。
考慮すべき各アプローチの利点のいくつかは次のとおりです。
単一データベース
複数のデータベース