2

私は半ダースのDBで作業しています。DB はすべて同じスキーマ、同じ SP などを持っています。最初に DB を設計した人に話すと、多くの DB を使用する動機の大部分は効率でした。別の方法は、データベース内のほぼすべてのテーブルと sp に列を追加して、どのデータセットが処理されているかを示し、複数の小さな DB ではなく 1 つの巨大な (したがって低速な) DB を作成することです。クエリ対象のデータ セットを示す列を使用する代わりに、接続文字列を使用して、ヒットするデータベースを選択します。

私がこの組織を本当に嫌いな唯一の理由は、コードの重複が多く、メンテナンスに負担がかかるからです。たとえば、ストアド プロシージャを変更するたびに、すべてのデータベースで alter ステートメントを実行する必要があります。

私が検討した解決策の 1 つは、すべてのデータを 1 つの大きなデータベースに結合し、結合しなかった場合にデータがどのデータベースに存在するかを示す列をあちこちに追加することです。次に、この列の値ですべてのテーブルを分割できます。理論的には、これらすべての結果として、すべてのデータ自体の基本的な表現は、現在と道徳的に同じになりますが、インデックス、スキーマ、SP などの冗長性はありません。

私の質問はこれです：

  1. これは良い考えですか？これを達成するためのより良い方法はありますか？
  2. これを行う際に落とし穴はありますか？
  3. これはパフォーマンスに影響を与えますか?
4

3 に答える 3

3

誰もがいつかこれに対処します。私の個人的な意見では、複数のデータベースは裏側の痛みであり、高速ではありません。彼らはメンテナンスの頭痛のために苦痛です。インデックス作成が適切に設定されていれば、必要に応じて各テーブルに余分な列を追加しても、プロセスがそれほど遅くなることはありません。また、メンテナンスがはるかに簡単になります。さらに、複数の DB 間でトランザクションを実行するのは面倒で、MTC が関与する可能性があります。

ところで、単一のデータベースを使用することは、多くの場合、マルチテナント データベースと呼ばれます。これについては、少し調べてみるとよいでしょう。しかし、可能であれば、このような複数の DB は避けたいと思います。

于 2010-02-12T19:35:47.543 に答える
1

私はランディとは違う考えを持っています。

マルチテナント モデルには利点があります。

1 つには、データベースが 5 つある場合も 500 がある場合も、メンテナンスはそれほど大きな違いはありません。ある時点で、個々のデータベースのメンテナンスを検討するのをやめて、セットに注目します。はい、バックアップをシリアル化する必要があり、すべてのデータベースで一度にインデックスの再編成/再構築を実行することはできません。

しかし、多かれ少なかれ同一の複数のデータベースにまたがるコード変更の場合、余分な指を離さずに、複数のデータベースに対して実行する多くのことをスクリプト化する簡単な方法があります。私は SQLFarms Combine というツール (現在は JNetDirect から販売されています) を使用していますが、RedGate MultiScript など、試したことのないツールが他にもあります。

マルチテナント モデルで私が最も気に入っているのは、成長とスケーリングがあり、突然新しいデータベース サーバーが必要になった場合、テナントの 1 つ (たとえば、最もビジーな、または最も急速に成長している) を新しいサーバーに移動するのが非常に簡単だということです。誰もが同じデータベースに詰め込まれている場合、特にダウンタイムを最小限に抑える必要がある場合、データのみを抽出することは非常に困難になります。マルチテナント モデルでは、データベースのみのミラーリングをセットアップし、準備ができたらプライマリを切り替えることができます。

于 2010-02-12T19:43:53.287 に答える
0

これらのデータベースを組み合わせることに賛成です。2 番目の物理ディスクでの追加のインデックス作成、パーティショニング、クラスタリングなど、非常に大規模なデータベースの潜在的なパフォーマンスの低下を考慮して、SQL Server には他の機能が組み込まれています。多くの異なるデータベースにスキーマの更新を展開することに伴う頭痛とオーバーヘッド単一のデータベースで簡単に処理できると、時間がかかることがあります。このような場合、SQL Server は非常にうまく拡張できると思います。データベース サーバーに設計どおりの処理をさせ、データへの応答性の高いアクセスを提供します。アプリケーションの設計に専念し、ストレージ モデルは SQL Server に任せることができます。

また、これは上記では言及されていませんが、この「多くのデータベース」モデルを使用するアプリケーションには、ある程度の動的 SQL が関与していると思われます。アプリケーションや構成ファイルにハードコードすることはできません。つまり、接続文字列または実際の SQL ステートメントをその場で生成する必要があり、これは非常に大きなセキュリティ リスクになる可能性があります (「SQL インジェクション」について読んでください。動的 SQL の潜在的なリスクに慣れていない)。

于 2010-02-12T19:51:52.680 に答える