私は、多くのビジネス ユニットで使用されるアプリケーションの開発を依頼されました。アプリケーションは各ユニットで基本的に同じですが、基礎となるデータベースの構造を変更しない小さな手順の違いがあります。ビジネス ユニットごとに 1 つのデータベースを使用する必要がありますか、それともすべてのユニットに対して 1 つの大きなデータベースを使用する必要がありますか? ビジネスユニットは完全に分離されています
2 に答える
2
私の好みは、クライアントごとに1つのデータベースです。利点：
クライアントが大きくなりすぎると、簡単に移動できます。バックアップ、復元、接続文字列の変更、ブーム。彼らのデータが大規模なデータベースで他の人と混ざっているときにそれをやってみてください。スキーマとファイルグループを使用して分離する場合でも、それらを移動するのは簡単なことではありません。
クライアントが先に進むときにクライアントのデータを削除するための同上。
定義上、各クライアントのデータを個別に保持しています。これはしばしば欲求になり、時には必要になります。時にはそれは法的拘束力さえあります。
データベース内のすべてのコードはより単純です。クライアントのスキーマ（パラメーター化できない）を含める必要はなく、テーブルにクライアントを示す追加の列を散らかす必要もありません。
多くの人は、200または500のデータベースを管理することは10のデータベースを管理することよりもはるかに難しいと主張するでしょう。私の経験では、それは実際には何の違いもありません。物事を自動化するスクリプトを作成したり、インデックスのメンテナンスやバックアップジョブをずらしたりします。
潜在的な欠点は、インスタンスごとに4桁以上のデータベースの領域に入り、複数のサーバーを持つことを検討し始めた場合です（しきい値は実際にはワークロードとハードウェアに依存するため、私は番号）。システムを正しく構築し、2台目のサーバーを追加し、新しいデータベースを配置するのは非常に簡単です。繰り返しになりますが、アプリは各クライアントの接続文字列を認識している必要があります。異なるサーバーを使用して行うのは、接続文字列が指すインスタンスを変更することだけです。
あなたが見るべきdba.SEに関するいくつかの質問。それらはすべてSQLServerに関するものではありませんが、概念と課題の多くは普遍的です。
https://dba.stackexchange.com/questions/7924/one-big-database-vs-several-smaller-ones
于 2012-08-15T21:04:53.537 に答える
0
あなたの質問はデザインの質問です。それに答えるためには、構築したいシステムの要件を理解する必要があります。技術的な観点からは、SQL Server (または実際にはすべてのデータベース) はどちらのシナリオにも対応できます。
考えるべきことがいくつかあります。
最初の質問は、クライアントがデータをどの程度分離する必要があるかです。異なるビジネス ユニットからのデータを混合することは、場合によっては合法的ではない場合があります (たとえば、銀行の投資側と市場分析側)。このような状況では、個別のデータベースが解決策になります。
次の質問はセキュリティです。状況によっては、クライアントは、自分のデータが他のクライアントのデータと混在していることを知って非常に不快になることがあります。ちょっとしたミスで、機密情報がうっかり共有されてしまいます。これは、同じ会社の異なるビジネス ユニットでは問題にならない可能性があります。
さまざまなアップタイム要件、アップロード要件、カスタマイズ、およびおそらく他のツールとのやり取りに対処する必要がありますか? あるビジネス ユニットができるだけ早くカスタマイズを必要とし、他のビジネス ユニットが関心を持たない場合、別のデータベースが提案されます。
もう 1 つの考慮事項は、パフォーマンスです。このアプリケーションは高価なリソースを大量に使用しますか? その場合、アプリケーションを異なるデータベース (場合によっては異なるサーバー) に分割できることが非常に望ましい場合があります。
一方、多くのデータが共有されており、リポジトリが実際には同じ基本機能を持つ中央リポジトリである場合は、1 つのデータベースが適しています。
于 2012-08-15T21:08:49.277 に答える